DNSSEC is drastically less secure than TLS is, and is itself a monolithic PKI. My guess, after looking at that link, is that the author of that post has never read the DNSSEC specs.
> DNSSEC is drastically less secure than TLS is .... My guess, after looking at that link, is that the author of that post has never read the DNSSEC specs.
How so? The purpose of DNSSEC is to prevent the data from being tampered with (say, by a MitM or an evil caching resolver), does it not manage to do this?
> DNSSEC ... is itself a monolithic PKI.
It is many times better than a PKI with 128 independently and fully trusted CAs, since Evilco can't just go shopping for the most subvertible CA.
No, it doesn't manage to do that. Here's a laundry list of problems with DNSSEC:
* Amazingly, contrary to everything you'd expect about "secure DNS", DNSSEC does not in fact secure DNS queries from your machine. Instead, it delegates securing DNS to DNSSEC-enabled resolver servers. For securing the actual queries your computer makes, your browser is on its own. There's a whole different protocol, TSIG, intended to address that problem.
* DNSSEC has zero successful real-world deployments, and no existing integration with any TLS stack. DNSSEC obviously does nothing to secure your actual traffic; all it does is try to protect the name lookup. TLS protects both.
* DNSSEC does nothing to address all the other intercepts, from ARP to BGP4, that real traffic has to contend with. Once you go from name to IP address (or "cert" in the fairytale world where DNSSEC has replaced the CAs), you're on your own. TLS addresses all of these issues except for CA configuration.
* DNSSEC actually reduces the security of DNS in some ways: in order to authenticate "no such host", DNSSEC publishes a sort-of-encrypted list of all your hosts. There's a whole other standards group drama surrounding the proposals to resolve this problem (NSEC3, whitelies, etc).
* DNSSEC fails badly compared to TLS. When keys inevitably get screwed up in TLS, you get a browser click-through. There is no API support to recover from a "gethostbyname()" failure caused by DNSSEC. This sounds like a reliability problem, but it's actually a security problem, in the same sense as "the little blue key icon isn't big enough" is a security problem for SSL. We just don't know what the exploit is, because nobody has designed the "solution" for this problem.
* TLS has 15+ years of formal review (it is the most reviewed cryptosystem ever published). We still find things in it. DNSSEC has received nothing resembling the same scrutiny. It's ludicrous to believe we won't find horrible problems with it. You'd be asserting that a protocol co-designed by Paul Kocher will eventually fare worse than one designed by the IETF DNS working group. The IETF DNS working group would basically have to crush some of the smartest practical crypto people in the world.
* TLS is at least configurable (virtually all TLS problems are in fact user interface and configuration problems, not problems with the underlying system). You can nuke untrustworthy CAs. There is no clean way to opt in or out of different DNSSEC policies, as the drama surrounding DLV illustrates.
In the '90s, we designed web security to assume that DNS was insecure. That was a smart decision. "Security" means different things to different people. It's a policy decision. The end-to-end argument strongly suggests that it's something that can't be baked into the lower parts of the stack. DNSSEC is a step backwards. I think you can already see the indications of the problems it will cause just by looking at the places it already falls down.
What we need is a concerted effort to solve the security UI and policy problems that browsers have.
I'm not sure you understand what the post was suggesting. All it was suggesting is that instead of validating the SSL certificate sent by using the hardcoded certs in the browser, it's validated by doing a DNS lookup to retrieve a hash of the cert. Where DNSSEC is used to "secure" the validity of that lookup.
It could even be an addition to the protocol, so the validation is done as normal with the CA's certificates which are hardcoded in the browser, but then a DNS lookup is done as well. That would defend from unscrupulous CA's that create additional certificates for a domain and give them to government organisations.
The original post was suggesting that we augment SSL by using DNSSEC to distribute cert authenticators instead of CAs. I'm saying that, for a lot of reasons, grafting DNSSEC onto web security is a solution far inferior to simply keeping TLS and solving the UI and policy problems we inevitably need to solve anyways.
Some of the problems are inherent in having multiple trusted CAs, or third-party CAs. These can be mostly solved by merging the CA function into DNS, or (almost) completely solved by something like Perspectives.
Problems being:
* someone who wants a fake cert, can go shopping for the worst CA available. You as a site owner cannot specify a CA.
* in order to have a cert on your site, you have to pay off a third party. Otherwise the browsers will scream at your visitors that unknown https is more insecure than plain http. ubiquitous encryption requires that certs come "for free" with what you need to just have a presence (such as being bundled with the domain name because they're just an extra DNS record).
It is, I think, a little crazy to suggest that a very simple configuration problem with the best-tested security protocol on the Internet should be solved by a complete overhaul of a different core Internet protocol.
> * Amazingly, contrary to everything you'd expect about "secure DNS", DNSSEC does not in fact secure DNS queries from your machine. Instead, it delegates securing DNS to DNSSEC-enabled resolver servers. For securing the actual queries your computer makes, your browser is on its own. There's a whole different protocol, TSIG, intended to address that problem.
The stub resolver (library that provides gethostbyname() and friends to your browser) can in fact verify the DNSSEC signatures itself:
> In particular, stub resolvers can set the CD bit in a query. The CD (Checking Disabled) bit tells the recursive name server not to validate DNSSEC-signed data on behalf of the resolver, but to return the various DNSSEC resource record types, such as RRSIG and DNSKEY RRs, so that the resolver can perform the validation.
> But no common stub resolvers implement their own DNSSEC validation, so CD is rarely used.
I expect this will be fixed in rather short order once there's a reason to fix it (say, all the major zones are signed and there's a semi-standardized DNS-as-PKI record type). Actually, I see a 'libunbound-dev' in the debian repositories already, which looks like a validating DNS resolver library (along with unbound-host and a couple other associated packages). I'll have to go play with this...
I also see discussion from 2003 about this, regarding wheter "stub resolver" is an appropriate term for something smart enough to validate the signatures (but apparently no claims that the end-user resolver shouldn't set the CD bit, just what to call that resolver): http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003...
> * DNSSEC has zero successful real-world deployments, and no existing integration with any TLS stack. DNSSEC obviously does nothing to secure your actual traffic; all it does is try to protect the name lookup. TLS protects both.
Kinda hard to have a "real-world deployment" without the root signed... that said, there are some signed zones and there is https://itar.iana.org/ .
The idea is to have a way to use DNS as your PKI rather than a horde of independent CAs. TLS would still be used and work about the same (I'm guessing the only difference would be to check cert hashes against a DNS record instead of checking the signatures against a list of CA signing certs, not a protocol change at all).
How can TLS between you and a server protect the DNS lookup you use to locate that server?
> * DNSSEC does nothing to address all the other intercepts, from ARP to BGP4, that real traffic has to contend with. Once you go from name to IP address (or "cert" in the fairytale world where DNSSEC has replaced the CAs), you're on your own. TLS addresses all of these issues except for CA configuration.
...which can be addressed by using DNSSEC as a PKI.
> * DNSSEC actually reduces the security of DNS in some ways: in order to authenticate "no such host", DNSSEC publishes a sort-of-encrypted list of all your hosts. There's a whole other standards group drama surrounding the proposals to resolve this problem (NSEC3, whitelies, etc).
Not relevant, and apparently sufficiently resolved that there's a timeline to have everything signed within a couple years.
> * DNSSEC fails badly compared to TLS. When keys inevitably get screwed up in TLS, you get a browser click-through. There is no API support to recover from a "gethostbyname()" failure caused by DNSSEC. This sounds like a reliability problem, but it's actually a security problem, in the same sense as "the little blue key icon isn't big enough" is a security problem for SSL. We just don't know what the exploit is, because nobody has designed the "solution" for this problem.
Huh? People don't care about their TLS keys getting screwed up, because people will just click through that screen (security problem!). If people can't even find your site when your keys are screwed up, you'll actually care about making sure your keys are right.
> * TLS has 15+ years of formal review (it is the most reviewed cryptosystem ever published). We still find things in it. DNSSEC has received nothing resembling the same scrutiny. It's ludicrous to believe we won't find horrible problems with it. You'd be asserting that a protocol co-designed by Paul Kocher will eventually fare worse than one designed by the IETF DNS working group. The IETF DNS working group would basically have to crush some of the smartest practical crypto people in the world.
...DNSSEC is not in any way supposed to replace TLS, that would make absolutely no sense. But it can replace the CA infrastructure, with the result of making TLS (as commonly used) more secure.
> In the '90s, we designed web security to assume that DNS was insecure. That was a smart decision. "Security" means different things to different people. It's a policy decision. The end-to-end argument strongly suggests that it's something that can't be baked into the lower parts of the stack. DNSSEC is a step backwards. I think you can already see the indications of the problems it will cause just by looking at the places it already falls down.
How can it fall down, when it hasn't been set up yet? And how can "I know that this data is not forged" possibly be a step backwards from "this data could very well be fake, it's been known to happen"?
Hacker News really sucks for quoted point-by-point responses. I don't think that's an accident. Try writing standalone comments.
After more than 13 years of failed attempts to secure the DNS, you need to better than "we haven't actually tried it yet". DNSSEC enthusiasts could have made the same argument 8-9 years ago with the "original" DNSSEC protocol, which ended up being scrapped.
Meanwhile, the operational problems DNSSEC will cause are, I think, entirely relevant to DNSSEC's role in web security --- both because of the weaknesses in DNSSEC that would directly impact its utility as a CA (for instance, the role of stub resolvers), and because of the damage it could inflict on the rest of the stack.
