Hacker News Reader

Comment by teddyh | Hacker News Reader

If you don’t trust the DNS, you’re pretty much screwed anyhow. The solution to the “last mile” problem is to run a private resolver on each machine. The DNSSEC root KSK (master) key is 2048 bits, and the ZSK is due to change to 2048 bits this year, after careful consideration of all the factors.

View on HN

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.

You keep offering HPKP as a solution in a thread regarding an article that shows how HPKP sucks. Hence why we keep repeating the same point.

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.

> 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.

Uh. Certificates are issued by checking DNS entries, and you are saying that we don't have to trust it.

That is correct, yes.

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.

It's easy to "win" arguments if you cherry pick parts of them and ignore the rest.

It's easy to "win" arguments if you try to come of better, rather than seeking for mutual understanding.

(yep, this ain't really seeking for mutual understanding)

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.

Thank you.

Reply on news.ycombinator.com