Hacker News Reader

Comment by dlgeek | Hacker News Reader

What you're describing is called "DANE" - https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Requiring DANE to issue certs is like requiring a speedometer, running lights, turn signals, and a breathalyzer in order to ride a bicycle.

All you actually need is a stripped-down REST API (or some wireline protocol with 4 fields) and a TLS connection. No need to require DNS or DNSSEC at all.

The registrar generates a unique token for whatever the domain owner wants to manage a cert for that's based on their domain. "oj3942hur9h239rh9hr4394834r domain.com" or "92839ub9f93hh9hsjdksjd * .foo.domain.com", doesn't matter. CA makes a request with the token and the CSR, registrar looks at the CSR, finds the record matching the token, finds that the CSR matches the record, signs its reply "yes, this is valid" with its own key, and the CA obliges the user. You don't even need DNS to make the request if it's hosted on some static IPs.

If anyone's seriously waiting on DANE in order to resolve a handful of security vulnerabilities that affect the entire Internet (because at this point the entire Internet's security hinges on TLS), we might as well also wait for Jesus to come down from his bachelor pad in the sky and solve our national debt.

Right, but no major browser supports DANE (at least out of the box). Will that ever change?

Maybe. In the middle scenario where most first-to-recursive DNS calls are DPRIVE but the authoritatives overwhelmingly aren't you get free security by just checking the "use DNSSEC" box and so browsers may just begin doing that, maybe gradually or maybe as a result of a headline making incident. See also the curious case of TLS_FALLBACK_SCSV. (Basically if you don't implement SCSV then unsafe fallbacks are too dangerous to attempt, but anybody implementing SCSV doesn't need an unsafe fallback anyway, so, forget this new protocol feature just never do unsafe fallbacks, duh)

Once you're checking that box, DANE is almost free. Egos involved may determine that it's important to never technically do DANE, so as to save face, see also why TLS 1.3 isn't just named SSL 3.4 or SSL 4.0 even though that's what it "is" in some sense. But the effect, yes. If that scenario plays out it's what will happen.

One blocker for DNSSEC and thus DANE was deployability difficulties facing middleboxes. But middleboxes have choked so much else since that today "defeat middleboxes" is just table stakes. It was needed for TLS 1.3 and it's needed for QUIC and for HTTPS DNS records and... if you're defeating middleboxes anyway you might as well have DNSSEC.

It makes sense to expend the effort to defeat middleboxes when what you win is QUIC or TLS 1.3, both of which work immediately on the Internet today. It doesn't make nearly as much sense when the payback is DANE, is supported almost nowhere --- significantly less than 2% of domains.

This isn't a chicken-and-egg problem: domains can DNSSEC-sign now, without any middlebox interference, and overwhelmingly choose not to.

It is a chicken-and-egg problem though. DNSSEC requires additional infrastructure, especially for key rotation. Yes, it's not that hard (I set it up for the domains that I control) but it's also not just a record that you can set once and forget. It is beyond unsreasonable for widespread DNSSEC support from domains when browsers have been dragging their feet for years. There needs to be an actual benefit that comes with setting up DNSSEC before most will do it.

Anyways, this is one of multiple reasons DNSSEC simply isn't going to happen.

Reply on news.ycombinator.com