Hacker News Reader

Comment by tptacek | Hacker News Reader

Your counterproposal is simply to expand the number of individuals who get to make those global judgements!

How so? In the current regime, I can obtain a certificate automatically via ACME. if I control the domain, so to retain control over myexample.com, I need to trust the DNS infrastructure up to my TLD and trust every CA, including the "my secret key is return 4" crowd

In a DANE world, I need only trust the DNS authorities, and there are ways to boost trust in, e.g. the dot-com key management. (Could even go full ring signatures if we wanted.)

Someone over on foo.wtf.lol can't hurt me.

Two problems with this: first, it describes a spherical cow universe where there is only DANE; on Earth 1, widespread deployment of DANE would add to the number of trusted authorities, not restrict it. More importantly: it assumes a universe in which everyone leaves .COM, which is controlled by the US IC, and somehow finds a TLD that can be trusted both as a domain operator and a CA. When that institution is inevitably suborned by the IC, there will be no recourse, except to migrate like a hermit crab to some new TLD and wait for it to happen all over again.

Meanwhile: this CA is likely to be killed outright for this fuckup.

What stops our adding a record that requires DANE and a conventional CA? (Preload it like HSTS, if you'd like, to prevent US IC downgrade attacks if people stupidly configure DNSSEC to fail open.)

This way, fuckups like this CA can't hurt me because they couldn't break DANE and IC couldn't hurt me (more than they can already) because WebPKI would have to approve too.

I don't think the CA death penalty addresses the problem. Just as in the physical world, the death penalty isn't a perfect deterrent.

The fact that DANE doesn't work on all network paths and it's hard to predict which ones will fail. You have a preference not shared by ordinary computer users, that broken network paths should be loudly broken and not best-effort.

If you care this much about your root set, consider having Claude roll you a Chromium or Firefox with a user-controllable set of roots that you ruthlessly prune and manage. Unlike DANE, which simply isn't going to happen for a whole variety of reasons, your personal root program (I gift that term to you if you want the coinage) actually could help people with your preferences.

With RFC 9102, you don't need DNSSEC to work on all network paths. But it was smothered in the crib by browser vendors. Sad.

No, it didn't work. You could trivially SSL-strip it. Geoff Huston wrote at length about this at APNIC.

This is like, what you're up against when trying to discuss DNSSEC realistically: people who think DANE stapling was a viable path forward. An entire new generation of SSL-strippable connections; the last one took us 15 years to get rid of. Let's try that again!

Stripping of TLS generally is solved, so why would stripping of the extension in particular be a problem? The same kinds of solution work for both. TLS covers the extension list in the handshake hash, so what's the attack here?

An attacker with a compromised certificate MITMs the site, terminates and proxies TLS using the bad certificate, and the TLS UA never sees that it's supposed to enforce DANE too?

That's what ExtSupportLifetime is for. Other pinning approaches, e.g. HSTS-like preload lists, work too. Union them. You need only one of N mechanisms to say "my domain promises to staple DNSSEC" to make the browser expect it and fail hard if it's not there. But stapling is just a transitional measure anyway.

The better solution, of course, is to just fix DNSSEC so the problem doesn't occur in the first place. There's no need to staple and no opportunity to strip if you can verify the DNS resolution end to end.

So, in this "doesn't work" scenario, it just so happens that the very first client contact endpoint is via this MITM, and the certificate is compromised at this moment, and HSTS or something prevents stripping TLS entirely, and the endpoint isn't on a DANE preload list (although it is on the HSTS one!) and DNSSEC isn't working in the client's environment? All at once?

Yeah, right.

Who's going to use HSTS, and DANE, but not set the "I'm using DANE" bit in the HSTS config? And if you're not using HSTS, an attacker can just strip TLS anyway and you lose regardless.

So yeah, it does work, and the "doesn't work" failure mode is server misconfiguration.

HSTS doesn't fix the problem with stapling. You need a new form of HSTS that nobody has deployed, which makes "this is server misconfiguration" an especially funny argument.

And, of course, this is just to get you to the point where you can count on DANE stapling for sites you've already been introduced to!

You're not worried that you're kind of making my case for me? You're definitely kind of making my case for me.

In any universe in which we can revive DANE stapling, we can add a single bit to HSTS state that talks about it. You can't simultaneously do and not do software development.

Designing the feature is straightforward! It took the better part of a decade to get HSTS deployed.

I'd best get started with the RFC now then

Well I gues TLS is pointless then because HTTP still exists. The point is obviously to eventually completely distrust centralized CAs.

Reply on news.ycombinator.com