Hacker News Reader

Comment by grevling123 | Hacker News Reader

Can we finally have DANE support in browsers now?

This all day. There is no reason I should have to go through a third-party to get a certificate just to distribute a key for secure communications (which is all a DV certificate is good for) if I already own a domain, or can get the domain owner to publish my TLSA record in theirs (which should be no more onerous than publishing the server A record, which they already have to do).

The reason we don't have DANE support in browsers is of course because Google decided not to implement it in Chrome, because (ultimately) the key lengths securing the root DNS server zones weren't large enough to suit them (at the time, 1024 bits):

https://www.imperialviolet.org/2015/01/17/notdane.html

And if Google wasn't going to do it, it didn't make sense for any other browser to do it either.

However, I believe the root zone keys are now longer, so I could (potentially) see Google implementing DANE in Chrome now, maybe with a Chrome-specific restriction of "TLSA records that have keys under 2048 bits in their chain of trust are ignored" (since the root zone keys are not the only keys in the chain and they want to eliminate 1024-bit RSA from Chrome). And if Google does it in Chrome, then everybody else has to do it too, so the situation flips.

DANE doesn't remove the requirement to get a 3rd party to vouch for your keys; it just locks you into one very specific 3rd party, one likely subject to de jure control of a state.

It seems much less likely that even a well-funded state actor could silently subvert enough root servers, which exist in many countries, to significantly compromise DNSSEC before alarms were raised, than that CAs are actively compromised or are just bad at being CAs, resulting in a breach like this (which happens approximately all the time). And with regard to state coercion, some CAs are in fact state-run, by states most people would consider grievously corrupt.

More to the point I would trust IANA and ICANN, faults and all, to not screw up the DNS/DNSSEC root, much more than I trust every CA in the default browser trust stores to get X.509 right all day, every day.

Again: you don't have to touch the root servers. The root servers are a red herring here. It's the TLD operators who exercise all the real control. IANA/ICANN will have nothing to do with the resulting situation.

See my other comment above. A malicious TLD operator is not something everyone is just powerless to deal with.

Short summary of my response to that comment: you're wrong, and ICANN does not in fact have the real-world power to liberate .COM from the United States Government.

Unlike Google, Mozilla, Apple, Microsoft and the gazillion of US-based CAs who right now can mint certificates not just for .com but also for every other TLD? Those are all not beholden to the US government in your mind???

Guess which third party is already required to "vouch" for your in order to get a DV cert from the web PKI mafia?

No? DANE is a dead letter. It doesn't work reliably on all Internet paths; too many middleboxes flip out if they see a DNS packet that doesn't look like every other DNS packet. For many years, there was an effort to work around that with "DANE stapling", where the signed DANE records were tacked on to the TLS handshake. But that leaves a chicken/egg problem, because attackers can strip the DANE records out of the handshake. The project was abandoned several years ago, and with it any real prospect of DANE becoming mainstream.

I think that's for the best; there are much bigger problems with DANE/DNSSEC than TLS reliability.

I don't think (and wouldn't hope) this would be a flag-day thing where we stop using CA trust completely all at once and only use DANE afterward. DANE would become an option, disabled or secondary by default, that users could choose to use as a fallback if CA-based TLS validation fails. Eventually as adoption increased and the critical paths got cleaned up, DANE could become the default primary, with a fallback to CA trust if there's no valid response to a TLSA record request. Eventually as CA trust fell completely out of favor for most uses, it wouldn't be necessary for many clients to support it at all.

See, this doesn't work either. One of the core jobs you have designing a secure transport is avoiding downgrade attacks, and the construction you just outlined is not only downgradable, it's explicitly downgradable, as a feature. That's not going to happen.

So the answer is just to use only the weaker option forever?

No? There's a very specific technical problem that makes DNSSEC hard to deploy effectively. You can't just define it away. You have to pursue solutions that solve that problem. There's a whole huge solution space to draw from, but people are so path-dependent and so predisposed to like the IETF that DNSSEC is just the only discussion we seem to be able to have.

Fortunately, the WebPKI has been ratcheting (slowly) up security over the last 15 years, so when nothing else happens, which is what I predict, at least we'll be in a better place a decade from now.

Anything that doesn't eliminate the current model of "a whole pile of CAs of unknown and widely-varying reliability are ultimately-trusted by every TLS client in the world despite the numerous times that has caused serious problems for approximately everyone on the Internet" is IMHO not significantly better than what we have now. The trust is the problem, and shorter certificate lifetimes or restrictions on usage flags or the various other things trying to work around that issue don't solve it no matter how many of them are implemented -- they're bandaids on a shotgun wound.

But let's whiteboard for a bit: if you agree (as I assume you do) that the current situation is at least more insecure than it should be, and should ideally change fundamentally, and if you don't think DANE is the right fundamental change, what would you implement instead if you had the magic wand to make everyone agree to do it?

I would verify domain ownership using something other than DNS, and devise something more reliable than CAA records to lock down issuance authority. But I can't say enough how much I think DANE would be a direct step backwards for trustworthiness on the web. We would be immediately worse off in multiple ways. Any argument in favor of DANE has to work around the unreliability, the weak cryptography, and, most importantly, the lack of transparency.

The problem today is that the browser vendors decide who is allowed to have a web presence on their domain.

Reply on news.ycombinator.com