5 ms·

>DNSSEC is quite famously a solution in search of a problem. I've only seen this sentiment every now and then in very particular circles. It's not really that

>DNSSEC is quite famously a solution in search of a problem. I've only seen this sentiment every now and then in very particular circles. It's not really that famous.

tptacek 8y ago
Here's a fun exercise: find the most reputable security or cryptography person you can that has publicly said nice things about DNSSEC. For extra fun, try to find one that isn't in some way affiliated with the IETF (most security and cryptography people aren't, so that shouldn't be too hard).
- kadendogthing 8y ago
  Well I don't know about people but I do know that a lot of big names in networking support and enable DNSSEC by default. So again, the sentiment isn't that famous because it's a widely used security feature. named has it on by default. Here's a fun exercise: You could just say what you need to say to make a point and educate the people reading this thread. Otherwise your comment is kind of detracting from constructive conversation.
  - tptacek 8y ago
    Which big names would those be?
    - kadendogthing 8y ago
      >named has it on by default. I stated as such in my comment you're replying to. The software that basically everyone uses for DNS management. Google DNS supports it by default, requiring you to opt out. I gave you an example, it would be greatly appreciated for you to provide a substantive, informative comment about the problems with DNSSEC or at the very least provide other material authored by other people (blogs/articles/etc) who are famous security experts who do not support DNSSEC -- you seem to know who to go to.
      - tptacek 8y ago
        Your argument is that DNSSEC has expert support and advocacy because the reference implementation of DNSSEC... exists? Yes: people who work on BIND probably do by and large support DNSSEC. Google does not generally support DNSSEC. It's easy to find Google security engineers criticizing it, but the most notable example would be AGL's "Why Not DANE In Browsers", which discusses why Chrome stopped supporting DNSSEC. https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html
        kadendogthing 8y ago
        >Your argument is that DNSSEC has expert support and advocacy because the reference implementation of DNSSEC. Actually if you read exactly what I wrote I merely countered that it's not a famous sentiment, which the comment I was replying to said it was. I said it was a sentiment only seen, at least from my perspective, in particular circles and really only in passing. I would consider the fact that Google DNS and named support it by default to be a significantly appropriate counter to the whole "everyone knows this isn't really a good tool/specification" sentiment. And it's an excellent negation of "it's easy to find Google engineers criticizing it" when their own service and the company they work/did work for is using it by default with their DNS service. Indeed, while I thank you for actually linking something I and others can read, the fact that some engineer in the ether -- and not to impugn his work, credibility, or how well he is known in certain circles -- is writing on the subject doesn't really have the same publicity as services and defacto software enabling DNNSEC by default. Here's the important point: Because of the above, to the passing eye or as mere consumers of these tools and services it looks like a specification that would probably be a good idea and a credible one at that. There is nothing "famous" about it falling short, or being a solution in search of a problem when everyone who really matters in this space is using it. Surely you must see that. Again thanks for the reading material, it is very much appreciated.
  - nothrabannosir 8y ago
    It was the first thing he said: there are very few real attacks that DNSSEC protects against. In other words: the benefit does not outweigh the cost. That is a damning argument and there is nothing else to say, until someone (e.g. you, but don't feel pressured) comes forward with a good counter example.
    - kadendogthing 8y ago
      > there are very few real attacks that DNSSEC protects against. That's not a very good argument when you're talking about securing systems. We don't actively mitigate attacks based on the prevalence of known instances of that attack. You do so beforehand. Attack vectors, before they are ever or even actively used, are considered. The most relevant, recent, and well known example of this is heartbleed.
      - tptacek 8y ago
        Your best example of an attack mitigating by deploying a languishing IETF standard is Heartbleed, which was caused by the adoption of a languishing IETF standard extension to TLS.
        kadendogthing 8y ago
        Heartbleed was caused by a class of code error prevalent in the toolchain used to write that code. It was not caused by the specification itself. Here is the exact change if you're able to read the code: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h... -- if that is not within your skillset to read that change, the patch is essentially doing a bounds check on a set area of memory. The language being used is notorious for allowing this type of code error and is the source of many exploits and bugs. It has nothing to do with the specification. For some reading material see this wikipedia article on the subject: https://en.wikipedia.org/wiki/Buffer_over-read https://en.wikipedia.org/wiki/Buffer_over-read >Programming languages commonly associated with buffer over-reads include C and C++, which provide no built-in protection against using pointers to access data in any part of virtual memory, and which do not automatically check that reading data from a block of memory is safe; respective examples are attempting to read more elements than contained in an array, or failing to append a trailing terminator to a null-terminated string. Bounds checking can prevent buffer over-reads We mitigate against attack vectors before there are known instances of software using those attack vectors. I'm not sure why you want to argue against that, or even how because we do it all the time. Take Spectre/Meltdown as another example. Preemptive measures were taken before any known usage of that attack vector had been discovered.

>DNSSEC is quite famously a solution in search of a problem. I've only seen this sentiment every now and then in very particular circles. It's not really that famous.

tptacek 8y ago

Here's a fun exercise: find the most reputable security or cryptography person you can that has publicly said nice things about DNSSEC. For extra fun, try to find one that isn't in some way affiliated with the IETF (most security and cryptography people aren't, so that shouldn't be too hard).

kadendogthing 8y ago
Well I don't know about people but I do know that a lot of big names in networking support and enable DNSSEC by default. So again, the sentiment isn't that famous because it's a widely used security feature. named has it on by default. Here's a fun exercise: You could just say what you need to say to make a point and educate the people reading this thread. Otherwise your comment is kind of detracting from constructive conversation.
- tptacek 8y ago
  Which big names would those be?
  - kadendogthing 8y ago
    >named has it on by default. I stated as such in my comment you're replying to. The software that basically everyone uses for DNS management. Google DNS supports it by default, requiring you to opt out. I gave you an example, it would be greatly appreciated for you to provide a substantive, informative comment about the problems with DNSSEC or at the very least provide other material authored by other people (blogs/articles/etc) who are famous security experts who do not support DNSSEC -- you seem to know who to go to.
    - tptacek 8y ago
      Your argument is that DNSSEC has expert support and advocacy because the reference implementation of DNSSEC... exists? Yes: people who work on BIND probably do by and large support DNSSEC. Google does not generally support DNSSEC. It's easy to find Google security engineers criticizing it, but the most notable example would be AGL's "Why Not DANE In Browsers", which discusses why Chrome stopped supporting DNSSEC. https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html
      - kadendogthing 8y ago
        >Your argument is that DNSSEC has expert support and advocacy because the reference implementation of DNSSEC. Actually if you read exactly what I wrote I merely countered that it's not a famous sentiment, which the comment I was replying to said it was. I said it was a sentiment only seen, at least from my perspective, in particular circles and really only in passing. I would consider the fact that Google DNS and named support it by default to be a significantly appropriate counter to the whole "everyone knows this isn't really a good tool/specification" sentiment. And it's an excellent negation of "it's easy to find Google engineers criticizing it" when their own service and the company they work/did work for is using it by default with their DNS service. Indeed, while I thank you for actually linking something I and others can read, the fact that some engineer in the ether -- and not to impugn his work, credibility, or how well he is known in certain circles -- is writing on the subject doesn't really have the same publicity as services and defacto software enabling DNNSEC by default. Here's the important point: Because of the above, to the passing eye or as mere consumers of these tools and services it looks like a specification that would probably be a good idea and a credible one at that. There is nothing "famous" about it falling short, or being a solution in search of a problem when everyone who really matters in this space is using it. Surely you must see that. Again thanks for the reading material, it is very much appreciated.
- nothrabannosir 8y ago
  It was the first thing he said: there are very few real attacks that DNSSEC protects against. In other words: the benefit does not outweigh the cost. That is a damning argument and there is nothing else to say, until someone (e.g. you, but don't feel pressured) comes forward with a good counter example.
  - kadendogthing 8y ago
    > there are very few real attacks that DNSSEC protects against. That's not a very good argument when you're talking about securing systems. We don't actively mitigate attacks based on the prevalence of known instances of that attack. You do so beforehand. Attack vectors, before they are ever or even actively used, are considered. The most relevant, recent, and well known example of this is heartbleed.
    - tptacek 8y ago
      Your best example of an attack mitigating by deploying a languishing IETF standard is Heartbleed, which was caused by the adoption of a languishing IETF standard extension to TLS.
      - kadendogthing 8y ago
        Heartbleed was caused by a class of code error prevalent in the toolchain used to write that code. It was not caused by the specification itself. Here is the exact change if you're able to read the code: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h... -- if that is not within your skillset to read that change, the patch is essentially doing a bounds check on a set area of memory. The language being used is notorious for allowing this type of code error and is the source of many exploits and bugs. It has nothing to do with the specification. For some reading material see this wikipedia article on the subject: https://en.wikipedia.org/wiki/Buffer_over-read https://en.wikipedia.org/wiki/Buffer_over-read >Programming languages commonly associated with buffer over-reads include C and C++, which provide no built-in protection against using pointers to access data in any part of virtual memory, and which do not automatically check that reading data from a block of memory is safe; respective examples are attempting to read more elements than contained in an array, or failing to append a trailing terminator to a null-terminated string. Bounds checking can prevent buffer over-reads We mitigate against attack vectors before there are known instances of software using those attack vectors. I'm not sure why you want to argue against that, or even how because we do it all the time. Take Spectre/Meltdown as another example. Preemptive measures were taken before any known usage of that attack vector had been discovered.