7 ms·

Actually, on a percentage of zones signed basis, or queries issued, DNSSEC penetration shrinks each day. He mentions encryption since the vast majority of peop

by davidu 12y ago

Actually, on a percentage of zones signed basis, or queries issued, DNSSEC penetration shrinks each day. He mentions encryption since the vast majority of people believe DNSSEC provides some level of privacy, encryption, or security. Most of us in the industry who aren't financially aligned to support DNSSEC recognize it does little to nothing in this area; while simultaneously adding complexity and brittleness. The only benefit DNSSEC offers (imho) right now is DANE-like services. And guess what? There are much easier ways to accomplish that.

axaxs 12y ago
Percentage based statistics are just as misleading. To me this data only says that personal/adspam/squatter zones are growing at a faster rate than those with integrity considerations. In raw numbers, adoption is growing. The consensus is that DANE requires 2048 zsk, which none of the big players are using to my knowledge. In that regard, I think DANE is easier to replace at this point.
- tptacek 12y ago
  The number of DNS resolutions that occur in the US and Europe that use DNSSEC is, as a fraction of all DNS resolutions, below the noise floor. That's the correct metric, by the way: DNSSEC in use. DNSSEC realists are curmudgeonly about this stuff in part because DNSSEC advocates have been saying things like "DNSSEC is growing" since nineteen ninety-nine. DANE is even worse than plain-old DNSSEC. For those of you who don't know what it is: DANE allows the DNS to vouch for your certificates. In other words: whoever controls the DNS roots effectively controls your certificates. You can in some sense sum up the cryptographic competence of DNSSEC by observing, as you have, that many of its largest deployers still use RSA-1024. If you have any actual interest in cryptography, here's a fun little research project: go find out the padding format those deployments use. :)
  - danyork 12y ago
    > DANE is even worse than plain-old DNSSEC. For those of you who don't know what it is: DANE allows the DNS to vouch for your certificates. In other words: whoever controls the DNS roots effectively controls your certificates. Please explain to me HOW the person who controls the DNS roots controls my certicate? I take my TLS certificate (either a CA-signed cert or a self-signed cert) and I load either a fingerprint of the cert or the complete cert into a TLSA record in my DNS zone. I then sign that with my DNSSEC key (create an RRSIG record) and publish it in the zone. It's all under my control. (NOTE: For those not familiar with the DANE protocol please see RFC 6698 or resources here: https://www.internetsociety.org/deploy360/resources/dane/ https://www.internetsociety.org/deploy360/resources/dane/ )
    - MichaelGG 12y ago
      The DNS root can alter your records to be whatever they want. Sure, they can already change your MX now and get a CA to sign a new cert by intercepting the email. But a replacement protocol should have much better design goals.
      - tptacek 12y ago
        Yes. Just change the word "should" to "MUST".
      - danyork 12y ago
        How can the DNS root alter my records? Say my domain is "example.com" and I serve the zone out of my own authoritative DNS server running on my own host. I create a "www" record that I serve out pointing to my site's IP address. Leaving DNSSEC out for a moment, how can the DNS root alter my records? All the DNS root does is provide pointers to the .com authoritative name servers. The .com name servers provide pointers to my example.com name server. My example.com name server serves out the zone data.
        MichaelGG 12y ago
        I mean the TLD root. Aka the .com registrar.
  - danyork 12y ago
    > You can in some sense sum up the cryptographic competence of DNSSEC by observing, as you have, that many of its largest deployers still use RSA-1024. If you have any actual interest in cryptography ... you could also help improve the DANE protocol. The DANE Working Group within the IETF is open to all. The mailing list is at: https://www.ietf.org/mailman/listinfo/dane https://www.ietf.org/mailman/listinfo/dane FYI, the working group will be meeting Tuesday afternoon (July 22) here at IETF 90 in Toronto, Canada, from 16:40-18:40 EDT. Agenda is: https://datatracker.ietf.org/meeting/90/agenda/dane/ https://datatracker.ietf.org/meeting/90/agenda/dane/ Streaming audio is at: http://ietf90streaming.dnsalias.net/ietf/ietf902.m3u http://ietf90streaming.dnsalias.net/ietf/ietf902.m3u Jabber chat room at: dane@jabber.ietf.org You're certainly welcome to show up and ask questions about the crypto involved. :-)
    - tptacek 12y ago
      No, RSA-1024 does not sum up the cryptographic problems of DNSSEC. If it did, I would have just said that. "Actual" interest in cryptography?
      - axaxs 12y ago
        You managed to successfully refute and argue with...yourself I think.
      - danyork 12y ago
        >"Actual" interest in cryptography? I was replying to your reply and quoted part of your message and just snipped it off without really indicating that I had just ended it. The way it came out on the HN page it is hard to see that it was your message versus mine. :-(
        tptacek 12y ago
        RSA-1024 is an easy problem to fix; it's not baked into the protocol. Other crypto problems in DNSSEC, not so much, sorry.
  - xorcist 12y ago
    > whoever controls the DNS roots effectively controls your certificates This is misleading at best. He who controls the DNS root servers controls absolutely nothing. He who controls the DNS root zone could, in theory, re-delegate a whole top domain to a malicious third party and thereby control your domain via this new top domain, thereby get control of your DANE certs. Don't you think the Internet at large would notice, and immediately route around the problem? When was the last time you saw an illegitimate top domain transfer? Never, that's when.
    - tptacek 12y ago
      Even if it was true that targeted changes were impossible this would still be a bogus argument. But it isn't true; attacks can be carried out surgically against small targets.
      - danyork 12y ago
        How? Please explain how an attack can be carried out surgically against small targets from the root?
      - xorcist 12y ago
        Please elaborate further. You've been alluding to that is a series of comments here. If it's too much for a reply do it in a blog post somewhere. You will find that people take reasonable arguments a lot more seriously.
kijeda 12y ago
Who in the industry, whether they are "financially aligned" or not, claims that DNSSEC provides you with privacy or encryption? The DNS data is sent in the clear. No-one who uses DNSSEC is arguing it keeps your DNS records private. It is a straw man argument to suggest otherwise. DNSSEC is designed to provide tamper-evidence, not privacy.
- tptacek 12y ago
  It's not a straw man to point out that the protocol that ostensibly "secures the DNS" does not in fact encrypt DNS queries or responses. I wasn't merely saying that DNSSEC records are plaintext (though they are). I was pointing out that the last mile from server to resolver has no cryptography whatsoever. Resolvers don't speak DNSSEC to servers --- it's a server-to-server protocol. This is a common tactic among DNSSEC advocates. Observation oft he inexplicable lack of last-mile security --- the one place where the Internet could actually benefit from DNS security --- is dismissed as a "straw man". Yes, it's very inconvenient to arguments for DNSSEC adoption. No, that doesn't make it out-of-bounds.
  - danyork 12y ago
    > This is a common tactic among DNSSEC advocates. Hmm... as a "DNSSEC advocate", I can say that I've never dismissed the lack of last-mile security as a "straw man". It's a real issue - but NOT one that DNSSEC seeks to solve. Because of this issue, many of us who advocate DNSSEC also advocate that the DNSSEC validation happens as close as possible to the end user, including even within the applications used by the user. If not in the apps then in the operating system. And if not there then on the local network... but then you start expanding the zone of risk. For the DNSSEC integrity validation to be useful it needs to happen as close as possible to the user - OR have a secured connection between the user and their DNS resolver. From a DNSSEC advocacy point of view, I'm always glad when a provider of DNS resolvers turns on DNSSEC validation... but public DNS servers are farther away from the end user than I would personally like to see. It's a good first step... but we really need the integrity validation happening close to the user.
    - 12y ago

by davidu 12y ago

axaxs 12y ago

Percentage based statistics are just as misleading. To me this data only says that personal/adspam/squatter zones are growing at a faster rate than those with integrity considerations. In raw numbers, adoption is growing. The consensus is that DANE requires 2048 zsk, which none of the big players are using to my knowledge. In that regard, I think DANE is easier to replace at this point.

tptacek 12y ago
The number of DNS resolutions that occur in the US and Europe that use DNSSEC is, as a fraction of all DNS resolutions, below the noise floor. That's the correct metric, by the way: DNSSEC in use. DNSSEC realists are curmudgeonly about this stuff in part because DNSSEC advocates have been saying things like "DNSSEC is growing" since nineteen ninety-nine. DANE is even worse than plain-old DNSSEC. For those of you who don't know what it is: DANE allows the DNS to vouch for your certificates. In other words: whoever controls the DNS roots effectively controls your certificates. You can in some sense sum up the cryptographic competence of DNSSEC by observing, as you have, that many of its largest deployers still use RSA-1024. If you have any actual interest in cryptography, here's a fun little research project: go find out the padding format those deployments use. :)
- danyork 12y ago
  > DANE is even worse than plain-old DNSSEC. For those of you who don't know what it is: DANE allows the DNS to vouch for your certificates. In other words: whoever controls the DNS roots effectively controls your certificates. Please explain to me HOW the person who controls the DNS roots controls my certicate? I take my TLS certificate (either a CA-signed cert or a self-signed cert) and I load either a fingerprint of the cert or the complete cert into a TLSA record in my DNS zone. I then sign that with my DNSSEC key (create an RRSIG record) and publish it in the zone. It's all under my control. (NOTE: For those not familiar with the DANE protocol please see RFC 6698 or resources here: https://www.internetsociety.org/deploy360/resources/dane/ https://www.internetsociety.org/deploy360/resources/dane/ )
  - MichaelGG 12y ago
    The DNS root can alter your records to be whatever they want. Sure, they can already change your MX now and get a CA to sign a new cert by intercepting the email. But a replacement protocol should have much better design goals.
    - tptacek 12y ago
      Yes. Just change the word "should" to "MUST".
    - danyork 12y ago
      How can the DNS root alter my records? Say my domain is "example.com" and I serve the zone out of my own authoritative DNS server running on my own host. I create a "www" record that I serve out pointing to my site's IP address. Leaving DNSSEC out for a moment, how can the DNS root alter my records? All the DNS root does is provide pointers to the .com authoritative name servers. The .com name servers provide pointers to my example.com name server. My example.com name server serves out the zone data.
      - MichaelGG 12y ago
        I mean the TLD root. Aka the .com registrar.
- danyork 12y ago
  > You can in some sense sum up the cryptographic competence of DNSSEC by observing, as you have, that many of its largest deployers still use RSA-1024. If you have any actual interest in cryptography ... you could also help improve the DANE protocol. The DANE Working Group within the IETF is open to all. The mailing list is at: https://www.ietf.org/mailman/listinfo/dane https://www.ietf.org/mailman/listinfo/dane FYI, the working group will be meeting Tuesday afternoon (July 22) here at IETF 90 in Toronto, Canada, from 16:40-18:40 EDT. Agenda is: https://datatracker.ietf.org/meeting/90/agenda/dane/ https://datatracker.ietf.org/meeting/90/agenda/dane/ Streaming audio is at: http://ietf90streaming.dnsalias.net/ietf/ietf902.m3u http://ietf90streaming.dnsalias.net/ietf/ietf902.m3u Jabber chat room at: dane@jabber.ietf.org You're certainly welcome to show up and ask questions about the crypto involved. :-)
  - tptacek 12y ago
    No, RSA-1024 does not sum up the cryptographic problems of DNSSEC. If it did, I would have just said that. "Actual" interest in cryptography?
    - axaxs 12y ago
      You managed to successfully refute and argue with...yourself I think.
    - danyork 12y ago
      >"Actual" interest in cryptography? I was replying to your reply and quoted part of your message and just snipped it off without really indicating that I had just ended it. The way it came out on the HN page it is hard to see that it was your message versus mine. :-(
      - tptacek 12y ago
        RSA-1024 is an easy problem to fix; it's not baked into the protocol. Other crypto problems in DNSSEC, not so much, sorry.
- xorcist 12y ago
  > whoever controls the DNS roots effectively controls your certificates This is misleading at best. He who controls the DNS root servers controls absolutely nothing. He who controls the DNS root zone could, in theory, re-delegate a whole top domain to a malicious third party and thereby control your domain via this new top domain, thereby get control of your DANE certs. Don't you think the Internet at large would notice, and immediately route around the problem? When was the last time you saw an illegitimate top domain transfer? Never, that's when.
  - tptacek 12y ago
    Even if it was true that targeted changes were impossible this would still be a bogus argument. But it isn't true; attacks can be carried out surgically against small targets.
    - danyork 12y ago
      How? Please explain how an attack can be carried out surgically against small targets from the root?
    - xorcist 12y ago
      Please elaborate further. You've been alluding to that is a series of comments here. If it's too much for a reply do it in a blog post somewhere. You will find that people take reasonable arguments a lot more seriously.

kijeda 12y ago

Who in the industry, whether they are "financially aligned" or not, claims that DNSSEC provides you with privacy or encryption? The DNS data is sent in the clear. No-one who uses DNSSEC is arguing it keeps your DNS records private. It is a straw man argument to suggest otherwise. DNSSEC is designed to provide tamper-evidence, not privacy.

tptacek 12y ago
It's not a straw man to point out that the protocol that ostensibly "secures the DNS" does not in fact encrypt DNS queries or responses. I wasn't merely saying that DNSSEC records are plaintext (though they are). I was pointing out that the last mile from server to resolver has no cryptography whatsoever. Resolvers don't speak DNSSEC to servers --- it's a server-to-server protocol. This is a common tactic among DNSSEC advocates. Observation oft he inexplicable lack of last-mile security --- the one place where the Internet could actually benefit from DNS security --- is dismissed as a "straw man". Yes, it's very inconvenient to arguments for DNSSEC adoption. No, that doesn't make it out-of-bounds.
- danyork 12y ago
  > This is a common tactic among DNSSEC advocates. Hmm... as a "DNSSEC advocate", I can say that I've never dismissed the lack of last-mile security as a "straw man". It's a real issue - but NOT one that DNSSEC seeks to solve. Because of this issue, many of us who advocate DNSSEC also advocate that the DNSSEC validation happens as close as possible to the end user, including even within the applications used by the user. If not in the apps then in the operating system. And if not there then on the local network... but then you start expanding the zone of risk. For the DNSSEC integrity validation to be useful it needs to happen as close as possible to the user - OR have a secured connection between the user and their DNS resolver. From a DNSSEC advocacy point of view, I'm always glad when a provider of DNS resolvers turns on DNSSEC validation... but public DNS servers are farther away from the end user than I would personally like to see. It's a good first step... but we really need the integrity validation happening close to the user.
  - 12y ago