5 ms·

> 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

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

tptacek 17y ago
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.
- mike-cardwell 17y ago
  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.
  - tptacek 17y ago
    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.
    - tbrownaw 17y ago
      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).
      - tptacek 17y ago
        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.

tptacek 17y ago

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.

mike-cardwell 17y ago
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.
- tptacek 17y ago
  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.
  - tbrownaw 17y ago
    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).
    - tptacek 17y ago
      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.