> 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).
HPKP doesn't really solve these problems. It requires initialization, so a naive browser isn't protected at all. It also makes a bunch of smaller operators nervous because, if they lose their keys, it's game over. DANE gives a happy middle ground where you can easily re-key and only a small number of third parties can potentially tamper with the keying.
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.
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.