Hacker News new | past | comments | ask | show | jobs | submit login

TLS has demonstrated no such thing. Right now, you can still subvert most TLS deployments by subverting the DNS, because everyone trusts CAs who provide signatures that rely on unauthenticated MX record lookups followed by cleartext SMTP connections.

DNSCurve is a reasonable replacement for TSIG, and I'm all for deploying it on that basis, but it doesn't make sense to give up on signed records. Signed records are at least non-repudiable, which provides some disincentive against forging them at a higher level in the tree. The DNSCurve proposal is to basically just hand over your private keys to a bunch of machines that are probably owned and operated by third parties, in an environment where they can forge arbitrary records at will without any accountability.

Sure, there are problems with the DNS being a hierarchical protocol, but we still need authenticated DNS and we need it yesterday. DNSSEC isn't a great solution and we certainly can't stop at DNSSEC, but that doesn't mean we're better off without it. Unless you know something that I don't about the relevant politics, the alternative to DNSSEC is probably to wait another 10+ years for something else to gain traction, and I don't think we can afford to wait that long.




We are in fact better off without DNSSEC:

* DNSSEC bakes a hierarchical PKI controlled at the roots by world governments into the core of Internet connectivity, in a way that can't be policy-controlled by users.

* DNSSEC has a poorly-thought-out interaction with Internet security and security policy; when TLS validation fails, users get a click-through that allows them to proceed to the site anyways. No similar state machine is built into the overwhelming majority of programs that do DNS lookups. As a result, if anything goes wrong with your DNSSEC configuration, you will more or less vanish from the Internet. "gethostbyname()" doesn't include a popup dialog feature.

* Mainstream deployments of DNSSEC are based on 1990s crypto, including PKCS#1v1.5 RSA padding; at exactly the moment when the rest of the Internet is transitioning away from crappy old RSA protocols, DNSSEC doubles down on it.

* DNSSEC leaks internal hostnames to the Internet because the designers of the protocols prioritized authenticated denials (availability) over confidentiality. NSEC3 is a great illustration of how slapdash the protocol design is: in an attempt to plug that leak, the IETF standardized what is in effect a password hash (and a bad one) to help obscure internal hostnames. When challenged on why the Internet should adopt a 1990s password hash as an Internet core protocol security mechanism, DNSSEC proponents say, "well, well-managed domains make domain cuts carefully to solve this problem", as if any commercial network in the world actually does that.

* DNSSEC creates yet another huge amplifier for DDoS attacks, allowing trivially small requests to elicit gigantic responses from servers.

Now, two fun things to know about all these problems:

1. They are, unlike your citation of crappy CAs, baked in design flaws in the protocol. You can evict a CA that misbehaves or isn't careful about validation. The EFF or ACLU could run a program that would allow people to subscribe to a trusted subset of CAs. None of that is possible in DNSSEC, because DNSSEC's problems aren't implementation or deployment problems, but rather fundamental attributes of the system.

* For all its flaws, DNSSEC doesn't actually protect queries from end systems to servers: it is a server-to-server system that leaves end-user DNS queries unprotected and spoofable.

I don't think this system is something we need "yesterday".

I have a lot of random opinions and thoughts about things, including security things, that I come to because discussions in places like HN prompt me to develop those opinions. DNSSEC is not one of those things. I've been following DNSSEC standardization since... well, since DNSSEC was an effort of TIS Labs, which was owned by my employer, where I was building DNS security testing tools. I've particularly followed namedroppers since the early 00's, when the list drove Daniel Bernstein away from DNS standardization.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: