If DNSSEC had been deployed 10 years ago, Muammar Ghaddafi would have been BIT.LY's CA.
Maybe you wanted to say that tree-structured DNS with TLDs owned by governments is bad, but this is a problem of DNS, not DNSSEC.
DANE reduces parties able to issue rouge certificate from TLD owner + all CAs to TLD owner only.
Which can be solved by having bit.ly key validated by .ly key + Firefox key + LetsEncrypt key.
DNSSEC may have other architectural/mplementational faults but this property is not one of them. I believe this way of certification is the way forword for internet scale web of trust.
Firstly: "With TLS properly configured, DNSSEC adds nothing."
DNSSEC presents you with a valid, secure chain to know that the meta-data (encoded as TLSA) about the end-point you intend to communicate with is valid.
i.e. Grab the TLSA record for a hostname, validate the hostname (and TLSA record) via DNSSEC and then if the TLS certificate matches the details in the TLSA record you have confirmation that things are valid.
Secondly: "Securing DNS lookups isn’t a high-priority".
Then why there is a whole IETF WG dedicated to addressing it: https://datatracker.ietf.org/wg/dprive/about/
Thirdly: "The real threat to CAs is “the global adversary”
i.e. organisations like the NSA, GCHQ collating everything, everywhere.
Any reasonable person could spend an afternoon - not being paid - providing a counterpoint to each item raised. None of them are (currently) relevant and the only one that is/was is actually being address in the IETF working group linked above.
I agree: DNSSEC does do what it does do. The problem is that what it does do isn't meaningful and doesn't add real security. At the same time, DANE/TLSA does create a system in which we replace certificate authorities with an organization run by the US Government.
Having a CT-like feature for DNSSEC would be nice, though.
Obviously, there's a reason nobody is issuing Google certificates, despite the insecure DNS that appears to be the only obstacle to that happening. Flesh out why, and try to be specific. The point isn't really about Google, but about the fact that the Web PKI is more complicated than the CA BRs suggest, and has safeguards at multiple levels.
I am not arguing that the CA PKI is a good system. It is not. It's a wretched system. It's only my contention that DNSSEC is worse.
What people overlook is that on the modern Internet, browsers themselves form an ad hoc certificate surveillance network. If you get a certificate issued for a site that pins, or create a CT discrepancy, there is a very good chance Google and Mozilla are going to discover the CA responsible. And, as you can see, even if you operate the largest, most important CA on the Internet, Google will, if that happens, fuck your shit up.
If you want one (of many) dispositive arguments against DNSSEC, just consider that Google and Apple and Mozilla are not in fact in a position to fuck shit up for .COM. You can't revoke or distrust a TLD: the use of those TLDs is encoded into the brains of hundreds of millions of users. Not so a CA!
Let's Encrypt absolutely would be happy to issue you a certificate for my web site if you can use DNS to convince them you control it.
Why not for GOOGLE.IO? Well Google is very famous, and CAs are obliged to have a "High risk" policy that identifies some names as "High risk" and requires human oversight for those names. Google is probably on every high risk list ever formulated. For Let's Encrypt since they have zero humans in their validation process, the "High risk" list is a blacklist, you just get an error "Policy forbids issuing" instead of your certificate.
But "High risk" doesn't scale. It protects Google, Microsoft, HSBC, Amazon, but it's not going to protect me or most other people.
CAA protects more broadly, but it doesn't protect you against somebody with control over DNS, because it needs DNS records to work, so they could just remove or alter the records. Also CAA is only just recently becoming mandatory, it can't save you if it's ignored by the CA.
I suspect the real issue is that the DNS protocol makes it extremely awkward for client machines to do full DNSSEC validation -- the normal approach is to see the AD bit and to blindly trust the upstream resolver, and this is obviously a complete non-starter for DANE.
Second, why is this a compelling argument? The first 2 TLSA usages are essentially what we already have: HPKP, bootstrapped from the DNS. HPKP's competition, TACK, worked the same way and didn't require DNSSEC at all. Further: all the problems people have with pinning (certificate suicide) remain in place with TLSA 0 and 1.
So basically this argument is: "that's a straw man because there's a way to deploy DANE where it doesn't accomplish anything and that's probably the only way DANE will ever be deployed so none of this matters". I am willing to stipulate that's the case.
Whoops. Usages 0 and 1, then.
> Second, why is this a compelling argument? The first 2 TLSA usages are essentially what we already have: HPKP, bootstrapped from the DNS.
TLSA usages 1 and 2 bootstrap off something that still works even if you've never visited the site before (or if you're in private browsing mode, etc). HPKP can't do that unless you preload.
> Further: all the problems people have with pinning (certificate suicide) remain in place with TLSA 0 and 1.
That's just not true. You can set a reasonable TTL and rescue yourself in a timely manner from a lost certificate without significantly impacting security. With HPKP, if you set a very short expiration, you lost almost all of your security.