> Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community --- the TLDs are controlled by world governments, as we all know from watching the DOJ use that control to attack file sharing sites.

I'm all for trying to reduce the need to trust one's government, but I think this is getting out of hand.

Currently, if you really want to trust the little https lock icon, you need to trust your government, pretty much everyone else's government, a whole lot of non-governmental companies of which many are demonstrably untrustworthy, and anyone who can hijack internet traffic well enough to spoof domain validation. And you need to trust everyone with control over DNS, because they can very easily spoof domain validation. That's a lot of people, any of whom can force a certificate.

With DANE, you need to trust the DNSSEC roots and the hierarchy from the roots to your domain. That's it.

So the argument that Verisign and your registrar (and presumably your government) can potentially defeat DANE is an argument against a ridiculous straw man: Verisign and your registrar can defeat the existing system just as easily.

At least with DANE, a whole bunch of other governments, registrars, AS operators, etc can't also impersonate your web site.

If a site deploys certificate pinning via HPKP, you don't need to trust anyone other than whoever the site deems trustworthy. So why bother with a new system that might be an improvement for a small subset of the trust problem (and comes with a huge set of other problems) when we already have a system that's supported by a large number of browsers, is in use by a number of high-profile sites and has shown that is effective against compromised CAs in the past?

Of course you can argue that HPKP is not quite there yet, but that is also true for DNSSEC in general, and even more true for DANE. If we somehow, against all odds end up in a situation where DNSSEC is actually widely deployed, it wouldn't even be a bad thing for the domain validation process in general - preventing at least some attack vectors, though I'd argue it's not worth the cost. However, it should never be a replacement for efforts like certificate pinning, Certificate Transparency, etc.

I don't think that I or anyone else has suggested that DANE is in any respect whatsoever a replacement for HPKP. DANE could partially replace or augment the CA system.

IMO we would ideally use DANE and HPKP with CA roots kept around for legacy clients.

The threat model you described did not take HPKP into account at all, and the existence of HPKP has a large effect on the question of whether DANE is worth the hassle (and the problems it comes with).

No, that is only half the HPKP story. The other half is that when a pin breaks in a browser, the browser can report it. Your browser might not have a certificate pinned yet (though: for the most important sites on the Internet, it does, because they're preloaded). But hundreds of thousands of other browsers do.

Every HPKP-enabled browser functions as part of a global surveillance system monitoring certificate issuance.

This works because under the TLS CA hierarchy, we have trust agility. When a CA screws up badly, they can be limited by the browsers (Chrome has repeatedly shown themselves willing to do that), or removed entirely.

DNSSEC+DANE gives us no trust agility. You cannot revoke .COM without breaking the Internet.

> Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community

That's not new; it just makes plain what has always been the case. Better to have it out in the open, IMO.

The legacy non-CC TLDs (.COM, .NET, etc.) are essentially US territory for historical reasons -- .COM should really be ".CO.US" but the latter will probably never catch on, and the ship has sailed at this point -- and anything under .UK is the UK's, obviously. If you don't want your DNS controlled by a FVEYs country, probably best not to use a TLD that's under one of those countries' control.

Setting up something in .COM that's likely to be objectionable to the US government is as unwise as setting up something that the Chinese government is going to find objectionable in .CN DNS space.

The idea that the Internet would ever somehow transcend nations, when it relies on infrastructure that lives in the physical world which is dominated by nation-states, was a naive piece of 1990s idealism. The fact that the Internet lets you basically choose your jurisdiction is a great thing, and shouldn't be undervalued. I don't think there has ever been a time when a person in the US could so easily set up a publication that's protected under the laws of (say) Finland, or Russia. (Of course, they do so at their own personal peril, if they live in the US; again, there's no escaping nations, just choosing between them or hiding.)

I am not totally sold on the DNSSEC+DANE concept, but the fact that it admits reality as it exists on the ground, which is that the Internet exists of and in the world and not above it, does not strike me as a particularly compelling criticism.

It is simply not true that in the status quo, setting up a site under .COM gives the USG access to your TLS keys. As long as you're pinning certificates, governments can't generate fake certificates for your site without burning the CA that they suborned.

If we adopted DNSSEC+DANE --- and, make no mistake, we have not adopted it --- this status quo would no longer be the case. The DNS hierarchy has no trust agility. You can't burn .COM; if you do that, you break the whole Internet. The browser vendors can, will, and repeatedly have torched misbehaving CAs, and forced still more into Certificate Transparency programs. That's a capability we actually have today, without anyone doing anything, that we would lose in DANE-land.

This isn't a complicated argument. I'm surprised it's stayed live on this site for so long.

There are lots of other dealbreaker problems with DNSSEC! But this is the simplest of them.