5 ms·

It's not a very compelling argument against DNSSEC no. The solution is for the World to close down open DNS servers in the same way it did with open SMTP server

It's not a very compelling argument against DNSSEC no. The solution is for the World to close down open DNS servers in the same way it did with open SMTP servers. Granted, it was a lot easier to do with SMTP.

tptacek 14y ago
Or, we could simply not do DNSSEC. DNSSEC + many tens of millions of dollars of open redirector cleanup work is not an inherently better solution than simply not doing DNSSEC.
- mike-cardwell 14y ago
  DNSSEC does not cause DNS amplification attacks. It just makes them worse. If we want to stop DNS amplification attacks, "not doing DNSSEC" isn't the fix. Closing down open redirectors is. If we turned off DNSSEC tomorrow, we'd still see these attacks.
  - tptacek 14y ago
    DNSSEC doesn't cause DNS amplification attacks. It just makes them much, much worse. Meanwhile, DNSSEC itself provides minimal value (all online commerce on the Internet happens without DNSSEC today, and to a useful first approximation, none of today's online fraud depends on spoofing DNS).
    - mike-cardwell 14y ago
      Except that DNS needs to be secure before systems that rely on DNS being secure, are written.
      - tptacek 14y ago
        Three issues with that, from least to most important --- that is, (c) is the most important issue: (a) DNSSEC doesn't actually do a good job of making the DNS secure (for instance, it doesn't secure the "last mile" between desktops and recursive resolvers). (b) Securing the DNS doesn't automatically secure the other core protocols that also need to be secure to rely on DNS promises; an IP address is still just an insecure IP address even if you learn about it from an RSA-signed message. (c) There's no compelling case that the DNS needs to be secure, or that we need systems that rely on a secure DNS. A secure DNS doesn't make it any easier to clear credit card transactions, to transfer funds, or to create secure & anonymous messaging systems. It seems to me that if DNS security was such a serious problem, it would be easier to come up with a scenario that benefited from it; that is, you wouldn't need to handwave with a comment like "the DNS needs to be secure before systems that rely on DNS being secure are written". Well, sure, but that shouldn't make it hard to merely imagine such a system. What is it?
        mike-cardwell 14y ago
        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.
- peterwwillis 14y ago
  This seems like a stupid solution. Did they fix the FTP bounce attack by disabling all PORT commands forever? No. They disabled PORT being used for any host except the originator. Similarly, they could compromise here by only enabling DNSSEC for authorized clients, and keep the rest of the DNS records open for the world the way they work now. This of course does nothing to fix the pink elephant of protocols that rely on a source address in a UDP packet to shovel off data without any limits. DNSSEC is just one single feature that can be abused; i'm sure there are many more available in other protocols, and more yet to be invented.
  - tptacek 14y ago
    It would be a stupid solution if DNSSEC had some vital role to play in Internet security. But it clearly doesn't, as evidenced by the fact that virtually all high-volume commercial transactions conducted in the industrialized world in 2012 hit the Internet, and none of it is protected by DNSSEC. If I had to draw a pie chart explaining the rationale behind deploying DNSSEC, a 1/3 slice of that pie would be labeled "IETF's misguided effort to replace the broken TLS CA PKI with yet another PKI controlled largely by the same giant businesses", and the remaining 2/3 slice would be labeled "Self-perpetuating fallacy that DNS must be SEC'd the way IP was (unsuccessfully) SEC'd", or, less charitably, "Windmill tilting exercise on the part of standards bodies".
    - peterwwillis 14y ago
      I don't care about DNSSEC. I just think it's ridiculous to ignore the real flaw, which is that you can bounce DNS packets at anyone you want. If you want to strip away part of the protocol to fix an attack vector, why not just redact EDNS0? Or do what networks around the world already do and block all port 53 udp packets bigger than 512 bytes. We'll continue to have a size-limited and somewhat inflexible protocol, but at least DNS amplification will have an upper bound.
      - tptacek 14y ago
        You can't just wave a magic wand and make it so attackers can't bounce DNS packets, and so it actually does matter than one DNS feature makes those bounced packets much much larger than any other DNS feature.

tptacek 14y ago

Or, we could simply not do DNSSEC. DNSSEC + many tens of millions of dollars of open redirector cleanup work is not an inherently better solution than simply not doing DNSSEC.

mike-cardwell 14y ago
DNSSEC does not cause DNS amplification attacks. It just makes them worse. If we want to stop DNS amplification attacks, "not doing DNSSEC" isn't the fix. Closing down open redirectors is. If we turned off DNSSEC tomorrow, we'd still see these attacks.
- tptacek 14y ago
  DNSSEC doesn't cause DNS amplification attacks. It just makes them much, much worse. Meanwhile, DNSSEC itself provides minimal value (all online commerce on the Internet happens without DNSSEC today, and to a useful first approximation, none of today's online fraud depends on spoofing DNS).
  - mike-cardwell 14y ago
    Except that DNS needs to be secure before systems that rely on DNS being secure, are written.
    - tptacek 14y ago
      Three issues with that, from least to most important --- that is, (c) is the most important issue: (a) DNSSEC doesn't actually do a good job of making the DNS secure (for instance, it doesn't secure the "last mile" between desktops and recursive resolvers). (b) Securing the DNS doesn't automatically secure the other core protocols that also need to be secure to rely on DNS promises; an IP address is still just an insecure IP address even if you learn about it from an RSA-signed message. (c) There's no compelling case that the DNS needs to be secure, or that we need systems that rely on a secure DNS. A secure DNS doesn't make it any easier to clear credit card transactions, to transfer funds, or to create secure & anonymous messaging systems. It seems to me that if DNS security was such a serious problem, it would be easier to come up with a scenario that benefited from it; that is, you wouldn't need to handwave with a comment like "the DNS needs to be secure before systems that rely on DNS being secure are written". Well, sure, but that shouldn't make it hard to merely imagine such a system. What is it?
      - mike-cardwell 14y ago
        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.
peterwwillis 14y ago
This seems like a stupid solution. Did they fix the FTP bounce attack by disabling all PORT commands forever? No. They disabled PORT being used for any host except the originator. Similarly, they could compromise here by only enabling DNSSEC for authorized clients, and keep the rest of the DNS records open for the world the way they work now. This of course does nothing to fix the pink elephant of protocols that rely on a source address in a UDP packet to shovel off data without any limits. DNSSEC is just one single feature that can be abused; i'm sure there are many more available in other protocols, and more yet to be invented.
- tptacek 14y ago
  It would be a stupid solution if DNSSEC had some vital role to play in Internet security. But it clearly doesn't, as evidenced by the fact that virtually all high-volume commercial transactions conducted in the industrialized world in 2012 hit the Internet, and none of it is protected by DNSSEC. If I had to draw a pie chart explaining the rationale behind deploying DNSSEC, a 1/3 slice of that pie would be labeled "IETF's misguided effort to replace the broken TLS CA PKI with yet another PKI controlled largely by the same giant businesses", and the remaining 2/3 slice would be labeled "Self-perpetuating fallacy that DNS must be SEC'd the way IP was (unsuccessfully) SEC'd", or, less charitably, "Windmill tilting exercise on the part of standards bodies".
  - peterwwillis 14y ago
    I don't care about DNSSEC. I just think it's ridiculous to ignore the real flaw, which is that you can bounce DNS packets at anyone you want. If you want to strip away part of the protocol to fix an attack vector, why not just redact EDNS0? Or do what networks around the world already do and block all port 53 udp packets bigger than 512 bytes. We'll continue to have a size-limited and somewhat inflexible protocol, but at least DNS amplification will have an upper bound.
    - tptacek 14y ago
      You can't just wave a magic wand and make it so attackers can't bounce DNS packets, and so it actually does matter than one DNS feature makes those bounced packets much much larger than any other DNS feature.