5 ms·

>Let's kill it off and focus on efforts that solve real problems Like what? It's pointless to distract from constructive proposals with no supporting material

>Let's kill it off and focus on efforts that solve real problems Like what? It's pointless to distract from constructive proposals with no supporting material for what the problems are with the proposed solution, and then claim there are other things that need our attention and then not even pay lip service to them.

ryanlol 8y ago
DNSSEC is strictly not a constructive proposal.
- kadendogthing 8y ago
  Oh okay.
jcranmer 8y ago
DNSSEC is quite famously a solution in search of a problem. It's pretty explicitly designed to secure the requests from the resolver to the nameservers, not from the actual end-users--and the number of actual attacks that would be prevented as a result are pretty damn minuscule.
- phicoh 8y ago
  DNSSEC works perfectly fine for securing requests from end-users. Of course you need to link your application with a DNSSEC-validating library. But that's just a small matter of code. Things become slightly more complicated when you have to deal with broken home routers. But that code exists as well.
  - tptacek 8y ago
    No, it doesn't. DNSSEC is a server-to-server protocol. Your caching resolver, after completing a DNSSEC-signed lookup, signals your stub resolver that the request was "secure" by means of a single header bit. There is no security whatsoever between client resolvers and DNSSEC servers. What you meant to say was that DNSSEC works "perfectly fine for securing requests from end-users" so long as they run their own DNSSEC cache servers. But of course, nobody is going to do that. They'll run DoH/DoTLS instead.
    - phicoh 8y ago
      DNSSEC validation has nothing to do with 'servers'. Maybe you want to take a look at, for example, https://getdnsapi.net/ https://getdnsapi.net/ Please stop spreading misinformation. Another example, openssh can locally do DNSSEC validation of SSHFP records (using the ldns library). Unfortunately, it doesn't really work, but that is a different story. All of the validation code is there.
      - tptacek 8y ago
        You don't seem to understand the difference between the resolver in a DNS cache server and a stub resolver. The stub DNS resolver on your desktop computer, as a general rule, does not do lookups from the DNS root all the way down to whatever leaf authority server holds the record it's trying to find. That's the job of caching resolvers --- the ones that live in servers like 8.8.8.8 and 1.1.1.1 (or whatever janky server your ISP or IT department sets you up with). If you're talking to a "DNS server" from your desktop --- like, you know, almost everyone on the Internet does --- you're not doing DNSSEC and, obviously, can't, because you've delegated to your DNS server the job of making all the intermediate requests needed to validate the chain of signatures to the root. A search term you might find helpful: [DNS header AD bit].
        deleted 8y ago
        [deleted]
        Abekkus 8y ago
        You can run a local resolver that forwards all queries to 8.8.8.8 while still running dnssec validation, and get both the speed benefit of a caching infrastructure, and the authentication of dnssec. With only one trusted key.
        tptacek 8y ago
        Yes, DNSSEC works fine for endpoints if we eliminate globally the concept of a DNS client and a shared cache and just have everyone run their own DNS servers.
- kadendogthing 8y ago
  >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.

ryanlol 8y ago

DNSSEC is strictly not a constructive proposal.

kadendogthing 8y ago
Oh okay.

jcranmer 8y ago

DNSSEC is quite famously a solution in search of a problem. It's pretty explicitly designed to secure the requests from the resolver to the nameservers, not from the actual end-users--and the number of actual attacks that would be prevented as a result are pretty damn minuscule.

phicoh 8y ago
DNSSEC works perfectly fine for securing requests from end-users. Of course you need to link your application with a DNSSEC-validating library. But that's just a small matter of code. Things become slightly more complicated when you have to deal with broken home routers. But that code exists as well.
- tptacek 8y ago
  No, it doesn't. DNSSEC is a server-to-server protocol. Your caching resolver, after completing a DNSSEC-signed lookup, signals your stub resolver that the request was "secure" by means of a single header bit. There is no security whatsoever between client resolvers and DNSSEC servers. What you meant to say was that DNSSEC works "perfectly fine for securing requests from end-users" so long as they run their own DNSSEC cache servers. But of course, nobody is going to do that. They'll run DoH/DoTLS instead.
  - phicoh 8y ago
    DNSSEC validation has nothing to do with 'servers'. Maybe you want to take a look at, for example, https://getdnsapi.net/ https://getdnsapi.net/ Please stop spreading misinformation. Another example, openssh can locally do DNSSEC validation of SSHFP records (using the ldns library). Unfortunately, it doesn't really work, but that is a different story. All of the validation code is there.
    - tptacek 8y ago
      You don't seem to understand the difference between the resolver in a DNS cache server and a stub resolver. The stub DNS resolver on your desktop computer, as a general rule, does not do lookups from the DNS root all the way down to whatever leaf authority server holds the record it's trying to find. That's the job of caching resolvers --- the ones that live in servers like 8.8.8.8 and 1.1.1.1 (or whatever janky server your ISP or IT department sets you up with). If you're talking to a "DNS server" from your desktop --- like, you know, almost everyone on the Internet does --- you're not doing DNSSEC and, obviously, can't, because you've delegated to your DNS server the job of making all the intermediate requests needed to validate the chain of signatures to the root. A search term you might find helpful: [DNS header AD bit].
      - deleted 8y ago
        [deleted]
      - Abekkus 8y ago
        You can run a local resolver that forwards all queries to 8.8.8.8 while still running dnssec validation, and get both the speed benefit of a caching infrastructure, and the authentication of dnssec. With only one trusted key.
        tptacek 8y ago
        Yes, DNSSEC works fine for endpoints if we eliminate globally the concept of a DNS client and a shared cache and just have everyone run their own DNS servers.
kadendogthing 8y ago
>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.