http://sockpuppet.org/blog/2015/01/15/against-dnssec/
I don't have a strong opinion on DNSSEC myself, but I agree with him that DANE is a bad replacement for standard TLS connections. DNSSEC is by far not the best security protocol ever designed, but it can protect to some threats, like cache poisoning.
Most of that post isn't about NSA controlling the Internet. It's about what a mess DNSSEC is, and how little it does to protect anything on the Internet even in a universe where it's actually deployed.
DNSSEC is Unnecessary
All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure.
DNSSEC is a Government-Controlled PKI
[...]
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
DNSSEC is Incomplete
[...]
In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.
DNSSEC is Unsafe
DNSSEC is Cryptographically Weak
There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here.
DNSSEC is a failed project, and a dodged bullet.
The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?
Also, if DANE is deployed, we can ditch CAs for non-EV certificates.
https://www.imperialviolet.org/2015/01/17/notdane.html
Second: you already can limit which CAs can issue a certificate for your domain, without forklifting out the DNS:
https://developer.mozilla.org/en-US/docs/Web/Security/Public...
Yes, there is HPKP, but it is "Trust on First Use" and adds entropy for browser fingerprinting.
Meanwhile: it's "trust on first use" for individual connections, but if you break a pin, your browser vendor will find out. It doesn't matter if a pin is broken for a minor reason or because some CA in Uzbekistan falsified the entire chain: either way, shenanigans get CAs penalized. It's happened repeatedly and will happen more and more.
Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record.
Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely.
Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
1. take away all the existing CA=YES certificates
2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars.
As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain.
2. Use public key pinning to restrict your domain to those CAs.
3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.)
If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
(And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.
DNSSEC is a complicated proposal with basically no adoption that requires widespread adoption to accomplish anything. We've had much better (though still not perfect) ways to improve authority-resolver security for years (DJB's DNSCurve for example). Given this, its only purpose is to make DANE happen. That benefit is way below the cost (again, maybe actual zero benefit depending on your point of view). It may even have a negative benefit by delaying a switch to an actually-good solution once someone figures one out (which nobody has, quite yet).