The CA system already uses the DNS as a trust anchor, and will continue to do so as long as DV certs are the standard. DANE likely would not have enabled any form of attack that isn't already possible.
What DANE would have done is end the madness that allows me to hack your wordpress blog for a day and then go get myself a certificate for your domain, for free, that doesn't expire for three years. A certificate you will never be able to detect the issue thereof and cannot easily revoke if you do.
And STS isn't an 'alternative' to DANE. The two are completely orthogonal
Arguments like this presuppose that the TLS security system is exactly as it was in 1999. But, of course, it isn't: major sites all pin certificates now, so that if you're well-equipped enough to subvert a CA and you use it to try to subvert a major site, there's a very good chance that literally all you'll accomplish is getting that entire CA blacklisted.
STS and DANE aren't orthogonal. DNSSEC/DANE offers such marginal value to HTTPS that the browsers that once offered pilot support for it have now eliminated that code; it is off the roadmap for the web. The remaining motivating use case for DNSSEC was SMTP security; DANE was a way to ensure that MTAs used secure transports and avoided downgrade attacks.
But STS does the same thing without requiring the forklift replacement of DNS that DNSSEC requires.
> Arguments like this presuppose that the TLS security system is exactly as it was in 1999
For the majority, it is. The % of sites that deploy all of the latest HTTPS bells and whistles, even just looking at the minority of sites that actually enable TLS, is in the low single digits. Only 8% of sites surveyed by Qualys SSL Labs... sites that are presumably run by people who care about security, unlike my bank, even bother to enable HSTS.
> major sites all pin certificates now
My bank doesn't. Enabling HPKP and HSTS is just risky from a commercial point-of-view. People aren't good at key management. If you botch it, you make your site inaccessible and you lose customers.
People screw it up all the time. I've done it. I was speaking to someone just today who was over-zealous with 'includeSubdomains' and made their product blog inaccessible (it was on a blog subdomain, which had an invalid TLS setup because wordpress.com don't support TLS on custom domains). It happens.
> if you're well-equipped enough to subvert a CA
Strawman, I never held this up as a threat. In any case, it's a bad defence of PKI. Being able to choose from N CAs doesn't help you. You only have to subvert one CA to own the world, just like DANE, where an attacker only has to break your registrar, or the domain registry, and you're toast. The 'world governments' you fear have the capability and thensome. Irrelevant.
The threat I explicitly mentioned is that if I own your DNS, I can get myself a cert for you domain. This has the same same threat models as DANE (if "owning your DNS" involves me compromising your DNS server and getting your DNSSEC keys, or guessing your domain registrar password), except DANE doesn't depend on horrible, ineffective, and privacy-invasive, hacks like OSCP... or allow me to simply keep certificates for domains I no longer own. DNS caching effectively gives you the equivalent of OCSP stapling for free.
> major sites all pin certificates now
TLSA records have all the configurability and capability of HPKP and more, and can be applied to any protocol/endpoint. They even cross the isle to work with the CA system if you so desire, unlike HSTS+HPKP which has become hostile to anything self-signed.
> STS and DANE aren't orthogonal
They are. DANE relates to key-pinning via TLSA records, not HSTS.
> forklift replacement of DNS that DNSSEC requires.
DNSSEC is backward compatible. You're talking twaddle. Enabling it these days, if you control your own DNS server, also takes seconds. With EC digital signatures, it's even sensible. Setting up HPKP+HSTS+OSCP stapling is far more fiddley...and stuck in the RSA stone age.
TLSA records do not have that capability, and, more importantly, the root of trust for TLSA records are organizations controlled by the government. The "Five Eyes" partnership can replace signatures for any DNSSEC domain in .COM, .NET, .ORG, .EDU, .UK, .AU, and .IO.
It seems crazy to me that, after years of hyperventilating about the implications of the Snowden disclosures, anyone could take DNSSEC seriously. But people do!
At this point, I'm just recapitulating things I've already written, so:
Your arguments does not make sense as a coherent whole. Any one may not be wrong in itself, but the problems described are either not inherent to secure DNS, or are something that is much worse with every other proposal (including keeping today's system).
1. Your main argument is that the NSA and its cohorts have control over a handful of many top level domains available. But the same control that would allow them to take control over domains and generate valid DNS signatures for them does allow them to generate valid certificates in every proposed global PKI system, including today's. There is literally zero difference in attack space here.
2. Several of the current CA institutions are under government control. Any one can generate a valid certificate for any domain. It can be done without a trace of evidence. The same active attack against a DNSSEC signed TLD would by necessity be much more visible.
3. Given that DV PKI is what TLS relies on, any adversary that can modify DNS packets in-flight can also create a valid TLS certificate today. We know these attacks are taking place from the Snowden documents.
4. An attacker can choose which CA to attack, and pick the one that is easiest to fool, does not participate in Certificate Transparency etc. There are literally hundreds to choose from. You can mount an attack in advance. Stuxnet suggests this is routine.
5. There are no alternatives that solves what secure DNS does. Key pinning and HSTS is important, but offer a trust-of-first-use model that can at best be complementary to a PKI. It is also important to note that HSTS shares the same deployment problems DNSSEC does. One mistake and your web server and domain is inaccessible. That is the reason none of the banks offer neither HSTS nor DANE. At least my bank sign their domain, so their step should be small.
The smoke-and-mirrors argument that DNSSEC gives governments control over "their" top level domains, when in fact it makes the scope of their control much smaller and more well defined, would be expected from someone who wants to maintain status quo as long as possible.
1. That example is not very useful. It's hard to blacklist .com, but it's even harder to blacklist Verisign. (Which by the way runs all of .com, and they have full power to delegate any domain and any certificate to anybody. This is not a theoretical attack.)
2/3. If you mean the FAQ you wrote yourself, it's misleading at this very point.
4. Pinning is useful, but it isn't a PKI. It's equally useful no matter how you issue certificates.
5. Domain name delegation are one of the Internet's weakest points today. Crypographic assurance of domain ownership would be very useful for a number of reasons.
Forged DNSSEC replies are inherently more public than forged TLS certificates, anybody can log the results and publish them.
And by doing so, the world would have evidence that somebody in that trust chain for that TLD has been lying. For TLS, that could be any CA in the world, which means that the number of single points of failure for services on DNSSEC is waaay lower. Because with DNSSEC you at least can chose who has the capability of forging results, with TLS alone that's all of the CA:s.
And why couldn't one combine the approaches anyway, using DNSSEC+DANE with certificate pinning? How would that possibly reduce security vs using standard DNS?
What DANE would have done is end the madness that allows me to hack your wordpress blog for a day and then go get myself a certificate for your domain, for free, that doesn't expire for three years. A certificate you will never be able to detect the issue thereof and cannot easily revoke if you do.
And STS isn't an 'alternative' to DANE. The two are completely orthogonal