First: no, not only is it not true that we must trust the DNS, but not having to trust the DNS is literally part of the thesis statement of SSL/TLS.
Second: you only need to break the weakest of the keys to attack the system. It's 2016, and we're talking about deploying a system that aspires to RSA-2048 or ECDSA, both of which are outmoded.
It actually gets worse. DNSSEC was designed in the mid-1990s with the assumption that cryptography was too expensive to deploy at scale. It's for this reason that DNSSEC uses signing-only constructions and requires support for offline signers: that is, support for people who will sign once, offline, and then never touch cryptography again.
All sorts of badness flows from support for offline signers. In particular: DNSSEC responses themselves are not encrypted. Despite relying on the most expensive cryptography primitive (public key signatures), the protocol offers no privacy at all.
This would be funny if it weren't for the fact that it turns out you need online signers anyways. Without online signers, there's no way to simultaneously (a) authenticate negative responses (ie: prevent someone from spoofing an NXDOMAIN response) and (b) not reveal all the names in a DNS zone. Surprisingly (at least to the people on the working group), pretty much everyone demands (b), and so pretty much every real-world DNSSEC deployment is an online-signer, so that it can synthesize NSEC records to trick out people trying to dump zones.
It's an incoherent protocol that deliberately handicaps itself in an attempt to achieve a design objective that turns out not to be possible to achieve.
Moreover: the more DNSSEC gets deployed today, the harder it will get to deploy fast, modern, misuse-resistant curve signature schemes. That's because anything you try to deploy on DNSSSEC needs to be supported by pretty much all the DNSSEC resolvers, because DNS is an infrastructure protocol, not an application-layer protocol.
It's for the same reason that DNSSEC failures cause sites to vanish completely from the Internet rather than generating pop-up warnings.
And how do you get a TLS certificate? By… proving that you control the DNS. Come back when there’s a working attack against the crypto of DNSSEC; being “outmoded” is not a security flaw. DNS is, on a very fundamental level cached, by slave servers, who does not, and should not, need to have access to the DNSSEC key to do live signing of records. DNSSEC was made for security, and explicitly not encryption – bringing up its lack of encryption like it’s a fundamental flaw in DNSSEC is a strawman argument. Regarding enumerating zones, you do know of the NSEC3 record (widely deployed for years) and the work on NSEC5, right? They were made to fix that, and, as I understand, were successful. Arguing against DNSSEC because we could in theory have something better reminds me of those arguing against SSL because the CA model is flawed. Sure it’s not perfect (what ever is?) but it’s what we have, and it’s better that the practical nothing we would have if we keep arguing about theoretical perfection over actual deployment of working code.
You are like the 9th person on this thread to make the same banal point about the relationship between DV certificates and the DNS. It's not accurate. See: rest of thread.
I don't so much mind people making the same arguments over and over again on different threads, but when you can read the thread and see the clever point you're about to make has already been litigated, I'm less sanguine.
The article doesn't show that HPKP "sucks". The article shows that HPKP can be dangerous. PKP isn't going anywhere, and we've been relying on it for years: it is likely that at least one CA has been penalized for breaking PKP pins.
This is very much unlike DNSSEC. True statement: we could publish the secret keys for the root ZSK on Pastebin today, and nothing on the Internet would break, because nobody relies on DNSSEC for their security.
Protocols that require online signing are impossible to cache and hard to scale. Even OCSP is often used with pre-produced offline signed responses for that reason (but they are periodically re-signed of course). So that's probably why DNSSEC supports offline signatures.
And while I agree that confidentiality of DNS would be a step in the right direction, there would still be many other leaks, e.g. the SNI field in TLS, or the destination IP address. To completely hide who is accessing which site, you'd need some kind of mixnet or onion routing.
Your usual example here is how hard it is to get a domain-auth cert for google.com, but what about a small e-commerce site? What should they do to prevent a bad guy from getting a domain-auth cert by spoofing DNS? Honestly asking for my education (and others).
They should get an OV cert and use HPKP for their domain. That is: if they're worried that a state-level attacker is going to MITM their users with a fake certificate.
OV certs do almost nothing to prevent MITM attacks. Unless you expect users to recognize when an OV cert is replaced with a DV one.
Moreover, HPKP means that I have to trust my first visit to a site. Any new site could be MITMed. Heck, HPKP means that anyone that gets to MITM your domain can wreck it for however long a Pin is valid.
Thanks. Is that attack only available to state-level attackers? I thought that--absent the measures you detail above--it was possible for a criminal enterprise to fool a CA into issuing a domain-authenticated cert.
The attack is too complicated for fraudsters, because it's multi-stage. They have to perpetrate a heist to get the certificate, and then another heist to MITM people to use the certificate (you can potentially use the DNS for both attacks, but they're still different attacks). DNS spoofing is not common in the real world, because it has low payoff.
Second: you only need to break the weakest of the keys to attack the system. It's 2016, and we're talking about deploying a system that aspires to RSA-2048 or ECDSA, both of which are outmoded.
It actually gets worse. DNSSEC was designed in the mid-1990s with the assumption that cryptography was too expensive to deploy at scale. It's for this reason that DNSSEC uses signing-only constructions and requires support for offline signers: that is, support for people who will sign once, offline, and then never touch cryptography again.
All sorts of badness flows from support for offline signers. In particular: DNSSEC responses themselves are not encrypted. Despite relying on the most expensive cryptography primitive (public key signatures), the protocol offers no privacy at all.
This would be funny if it weren't for the fact that it turns out you need online signers anyways. Without online signers, there's no way to simultaneously (a) authenticate negative responses (ie: prevent someone from spoofing an NXDOMAIN response) and (b) not reveal all the names in a DNS zone. Surprisingly (at least to the people on the working group), pretty much everyone demands (b), and so pretty much every real-world DNSSEC deployment is an online-signer, so that it can synthesize NSEC records to trick out people trying to dump zones.
It's an incoherent protocol that deliberately handicaps itself in an attempt to achieve a design objective that turns out not to be possible to achieve.
Moreover: the more DNSSEC gets deployed today, the harder it will get to deploy fast, modern, misuse-resistant curve signature schemes. That's because anything you try to deploy on DNSSSEC needs to be supported by pretty much all the DNSSEC resolvers, because DNS is an infrastructure protocol, not an application-layer protocol.
It's for the same reason that DNSSEC failures cause sites to vanish completely from the Internet rather than generating pop-up warnings.