3 ms·

You've convinced me. There is no conceivable benefit from a secure DNS, nor any possible application that could make use of such a thing.

tptacek 14y ago
I wish I felt like you were being sincere, since that actually is one of my arguments!
- mike-cardwell 14y ago
  I was being sarcastic because I (and everybody reading this comment, other than you apparently) could probably real off at least fifty use cases given an hour, so I found it hilarious that you were claiming that I couldn't even name one. I am not going to name one. You may now repeat your claim that the reason is because I can't think of one, for continued comedy affect.
  - tptacek 14y ago
    I'm not looking for fifty use cases. One would suffice to move the conversation forward. Maybe somebody besides you --- "anybody reading this comment" being able to generate "at least" fifty of them --- will provide one. It is not a subjective statement that Internet commerce doesn't rely at all on DNSSEC today. It's a fact.
    - comex 14y ago
      In theory? The use case is simple: we already trust the DNS roots a very great deal - aside from the fact that most of the Internet doesn't use HTTPS, getting a HTTPS certificate for a domain essentially comes down to proving to a neutral server that you control it - so if DNS responses could be verified and could include SSL certificates, which DNSSEC allows, we could obviate the need to trust the CA system, which has lately been proven vulnerable, without having to trust any new entities in exchange. I don't know much about the issues surrounding DNSSEC, so I wouldn't be surprised if they make this not worth it in practice.
      - tptacek 14y ago
        DNSSEC replaces one hierarchical PKI (the CA system) with another hierarchical PKI (the DNSSEC tree). Ironically, the dominant provider in both PKIs happens to be Verisign. One difference between the two PKIs is that the CA system admits to many different CAs, and to browser and even end-user control over which CAs are trustworthy. On the other hand, DNSSEC bakes its authorities into the core of the Internet. Don't like Verisign? Tough shit. A pithier way to say the same thing: Ghaddafi's Libya would at one point have been BIT.LY's "CA" in a DNSSEC world. The role of any PKI authority in the HTTPS/TLS ecology will diminish soon with something like TACK, which integrates key continuity with the TLS PKI. TACK doesn't require DNSSEC, but allows websites to "pin" their certificates into browsers so that even if Iran or China hacks your trust anchor, your site can overrule them. This is exactly the scheme Google uses today to protect its properties: no DNS record or CA signature will convince Chrome that you are the real GMail. The short answer to "replacing the CAs" as a use case for DNSSEC is that DNSSEC doesn't change the model or the security characteristics of HTTPS/TLS; it's at best a lateral move. But there are specific ways in which it makes HTTPS/TLS trust problems worse, and even more ways that it introduces reliability problems.
        comex 14y ago
        Yes, but that other hierarchical PKI is one that we already trust almost everywhere: although extended validation SSL certificates give you an idea of the legal entity in control of the site, in general the only thing it means to be the legitimate owner of a domain is for the DNS roots to recognize you as such. In particular, I don't know any system other than certificate pinning in which a rogue operator of .ly wouldn't be able to get a certificate for bit.ly, or even if that would be considered inherently illegitimate; I like the idea of alternative, decentralized DNS roots like .bit, but fixed authorities are what we're stuck with today. Making the entity that you trust the only entity that you trust is a strict improvement. And yes, certificate pinning is an exception, making the browser vendor the CA for a small number of domains, but Convergence and other systems depend on the DNS, and TACK only helps on subsequent visits to an already visited site.
        14y ago

tptacek 14y ago

I wish I felt like you were being sincere, since that actually is one of my arguments!

mike-cardwell 14y ago
I was being sarcastic because I (and everybody reading this comment, other than you apparently) could probably real off at least fifty use cases given an hour, so I found it hilarious that you were claiming that I couldn't even name one. I am not going to name one. You may now repeat your claim that the reason is because I can't think of one, for continued comedy affect.
- tptacek 14y ago
  I'm not looking for fifty use cases. One would suffice to move the conversation forward. Maybe somebody besides you --- "anybody reading this comment" being able to generate "at least" fifty of them --- will provide one. It is not a subjective statement that Internet commerce doesn't rely at all on DNSSEC today. It's a fact.
  - comex 14y ago
    In theory? The use case is simple: we already trust the DNS roots a very great deal - aside from the fact that most of the Internet doesn't use HTTPS, getting a HTTPS certificate for a domain essentially comes down to proving to a neutral server that you control it - so if DNS responses could be verified and could include SSL certificates, which DNSSEC allows, we could obviate the need to trust the CA system, which has lately been proven vulnerable, without having to trust any new entities in exchange. I don't know much about the issues surrounding DNSSEC, so I wouldn't be surprised if they make this not worth it in practice.
    - tptacek 14y ago
      DNSSEC replaces one hierarchical PKI (the CA system) with another hierarchical PKI (the DNSSEC tree). Ironically, the dominant provider in both PKIs happens to be Verisign. One difference between the two PKIs is that the CA system admits to many different CAs, and to browser and even end-user control over which CAs are trustworthy. On the other hand, DNSSEC bakes its authorities into the core of the Internet. Don't like Verisign? Tough shit. A pithier way to say the same thing: Ghaddafi's Libya would at one point have been BIT.LY's "CA" in a DNSSEC world. The role of any PKI authority in the HTTPS/TLS ecology will diminish soon with something like TACK, which integrates key continuity with the TLS PKI. TACK doesn't require DNSSEC, but allows websites to "pin" their certificates into browsers so that even if Iran or China hacks your trust anchor, your site can overrule them. This is exactly the scheme Google uses today to protect its properties: no DNS record or CA signature will convince Chrome that you are the real GMail. The short answer to "replacing the CAs" as a use case for DNSSEC is that DNSSEC doesn't change the model or the security characteristics of HTTPS/TLS; it's at best a lateral move. But there are specific ways in which it makes HTTPS/TLS trust problems worse, and even more ways that it introduces reliability problems.
      - comex 14y ago
        Yes, but that other hierarchical PKI is one that we already trust almost everywhere: although extended validation SSL certificates give you an idea of the legal entity in control of the site, in general the only thing it means to be the legitimate owner of a domain is for the DNS roots to recognize you as such. In particular, I don't know any system other than certificate pinning in which a rogue operator of .ly wouldn't be able to get a certificate for bit.ly, or even if that would be considered inherently illegitimate; I like the idea of alternative, decentralized DNS roots like .bit, but fixed authorities are what we're stuck with today. Making the entity that you trust the only entity that you trust is a strict improvement. And yes, certificate pinning is an exception, making the browser vendor the CA for a small number of domains, but Convergence and other systems depend on the DNS, and TACK only helps on subsequent visits to an already visited site.
        14y ago