6 ms·

Well, there's also a significant rate of adoption in Brazil. US domains await support from Godaddy et. al., with Godaddy recently announcing that DNSSEC will b

Well, there's also a significant rate of adoption in Brazil. US domains await support from Godaddy et. al., with Godaddy recently announcing that DNSSEC will be available as a standard offering, not just a premium option. Adoption barriers still exist, but are falling. I am not expecting miracles overnight, but I'm patiently playing the long game, and not too worried about the past or the status quo.

tptacek 7y ago
When it's like, a couple months, or even a year or so, sure, the past might not have much to tell you. But it's been twenty -five years. Even if you start at DNSSECbis, it's been almost 20 years since the typecode roll. At some point, ignoring the past stops being such a prudent strategy.
- ietf-dane 7y ago
  The timescales that matter are: 2010 - Root zone signed 2012 - Base DANE specification 2013 - First DANE SMTP draft, Snowden 2015 - SMTP DANE TLS RFC 2015 - DANE live at udmedia.de, mailbox.org, posteo.de, xs4all.nl, comcast.net, debian.org, freebsd.org, ... 2016 - DANE live at web.de, gmx.de, transip.nl, domeneshop.no, ... 2018 - one.com, ... Along the way, support for DANE in SMTP for Postfix, Exim, Halon, PowerMTA, MailChannels, ... Also OpenSSL and GnuTLS and now 1.88 million domains with DANE MX hosts. It has taken me seven years to get real momentum behind DANE for SMTP, and will likely take another seven to see how it plays out... You may not have the patience, but I am prepared to play the tortoise racing the sleeping hare.
  - tptacek 7y ago
    Even by the artificial timeline you provide, it's been 10 years since DNSSEC was rolled out in its current form in the root zone. That list of domains you've provided is almost the best you can do (you forgot Cloudflare). Open source software support for DANE doesn't mean anything. Open source software supported the TLS Heartbeat Extension, too.
    - ietf-dane 7y ago
      Cloudflare does not MX-host customer domains, so is not in scope, they DNS-host signed domains, but that's not what the above is about. Google also DNS-hosts many signed domains (under the cloud.goog, .dev and .app TLDs). I was listing DANE adoption since 2015, which is really when the clock starts, the signing of the root zone in 2010 was just a prerequisite, but not enough by itself. The DNSSEC use-case in question is DANE for SMTP, which was not possible earlier. The Heartbeat example is absurd. DANE support is in MTAs that actually use it, and not just some landmine in an open-source library. Some of the larger providers use commercial SMTP stacks that support DANE, others use open-source, but any analogy with Heartbeat other than it was also open-source is much too weak to warrant consideration.
      - tptacek 7y ago
        The point is simply that implementation in open source projects doesn't imply user (or even operator) adoption. It's not really a metric of anything. People want to build features like these; it's fun.
        ietf-dane 7y ago
        That's done and dusted, what's happening now for example is that today 7620 new .com domains got signed, ~73% of them by googledomains.com. And roughly the same thing is happening every day: https://stats.dnssec-tools.org/tld-graphs/com.png https://stats.dnssec-tools.org/tld-graphs/com.png Sure, if the pace stays the same it works out to about 2 million per year, which is cool, but there are over 140 million .com domains, so more than just Google would need to engage in large-scale signing. I am not denying that until recently things have been slow to moribund, but things have started to change, and where we part ways is that you've written off all possibility of change based on past stasis, but I'm ignoring it and having some real, if early, success at driving change. My take is that you're under no obligation to contribute or even admit that change is starting to happen, but I think it would be polite to back off on the negativity, just wait and see, you may be proved right without expending any energy being vocal about it. But if adoption picks up unexpectedly, allow yourself to be surprised...
- cryptonector 7y ago
  I mean, x.509 is even older, and yet we still don't have a real PKI. There's no reason to think that some technology being 25 years old means it's dead if not used already. We have to realistic paths to a true PKI, both based on DNS: a) DNSSEC, b) the registries/registrars operate name-constrained (as least as anchors) CAs. That's it. The WebPKI offers little real security. Certificate transparency is just like DNSSEC -- it needs big deployment to be a win, and it's especially needed because we don't trust the CAs because there's so many because they are not name constrained. In DNSSEC the trust problem is still there, so CT could be applied to DNSSEC, but if you use QName minimization then it's harder for the root zone and TLDs to decide when to MITM you -- that's a really strong characteristic that PKIX couldn't hope to have because it doesn't have a directory. (Stapling DNSSEC chains in TLS would defeat this, but it is needed for last mile reasons, such as hotel networks.)
  - tptacek 7y ago
    Nobody likes the WebPKI. But if you posted the private key for any trusted CA on Pastebin, it would be a very big deal. People around the world would get paged, and many of them would actually have to come in to work. Contrast that with DNSSEC. The root key for the entire Internet, the one they have the secret Stonecutters ceremony to establish, could end up on Pastebin tomorrow and nothing would happen. Nothing would happen the next day either. Weeks could elapse and nothing would happen. What's more, the comparison holds if you go back a year, 2 years, 10 years. The WebPKI is old (though evolving, unlike DNSSEC, for which things like transparency logs remain defensively evoked hypotheticals), but it has been important throughout it's life. Hell, the application of DNSSEC we're talking about here is subsidiary to the WebPKI --- it's simply making sure that mail servers speak WebPKI-secured TLS to each other!

tptacek 7y ago

When it's like, a couple months, or even a year or so, sure, the past might not have much to tell you. But it's been twenty -five years. Even if you start at DNSSECbis, it's been almost 20 years since the typecode roll. At some point, ignoring the past stops being such a prudent strategy.

ietf-dane 7y ago
The timescales that matter are: 2010 - Root zone signed 2012 - Base DANE specification 2013 - First DANE SMTP draft, Snowden 2015 - SMTP DANE TLS RFC 2015 - DANE live at udmedia.de, mailbox.org, posteo.de, xs4all.nl, comcast.net, debian.org, freebsd.org, ... 2016 - DANE live at web.de, gmx.de, transip.nl, domeneshop.no, ... 2018 - one.com, ... Along the way, support for DANE in SMTP for Postfix, Exim, Halon, PowerMTA, MailChannels, ... Also OpenSSL and GnuTLS and now 1.88 million domains with DANE MX hosts. It has taken me seven years to get real momentum behind DANE for SMTP, and will likely take another seven to see how it plays out... You may not have the patience, but I am prepared to play the tortoise racing the sleeping hare.
- tptacek 7y ago
  Even by the artificial timeline you provide, it's been 10 years since DNSSEC was rolled out in its current form in the root zone. That list of domains you've provided is almost the best you can do (you forgot Cloudflare). Open source software support for DANE doesn't mean anything. Open source software supported the TLS Heartbeat Extension, too.
  - ietf-dane 7y ago
    Cloudflare does not MX-host customer domains, so is not in scope, they DNS-host signed domains, but that's not what the above is about. Google also DNS-hosts many signed domains (under the cloud.goog, .dev and .app TLDs). I was listing DANE adoption since 2015, which is really when the clock starts, the signing of the root zone in 2010 was just a prerequisite, but not enough by itself. The DNSSEC use-case in question is DANE for SMTP, which was not possible earlier. The Heartbeat example is absurd. DANE support is in MTAs that actually use it, and not just some landmine in an open-source library. Some of the larger providers use commercial SMTP stacks that support DANE, others use open-source, but any analogy with Heartbeat other than it was also open-source is much too weak to warrant consideration.
    - tptacek 7y ago
      The point is simply that implementation in open source projects doesn't imply user (or even operator) adoption. It's not really a metric of anything. People want to build features like these; it's fun.
      - ietf-dane 7y ago
        That's done and dusted, what's happening now for example is that today 7620 new .com domains got signed, ~73% of them by googledomains.com. And roughly the same thing is happening every day: https://stats.dnssec-tools.org/tld-graphs/com.png https://stats.dnssec-tools.org/tld-graphs/com.png Sure, if the pace stays the same it works out to about 2 million per year, which is cool, but there are over 140 million .com domains, so more than just Google would need to engage in large-scale signing. I am not denying that until recently things have been slow to moribund, but things have started to change, and where we part ways is that you've written off all possibility of change based on past stasis, but I'm ignoring it and having some real, if early, success at driving change. My take is that you're under no obligation to contribute or even admit that change is starting to happen, but I think it would be polite to back off on the negativity, just wait and see, you may be proved right without expending any energy being vocal about it. But if adoption picks up unexpectedly, allow yourself to be surprised...
cryptonector 7y ago
I mean, x.509 is even older, and yet we still don't have a real PKI. There's no reason to think that some technology being 25 years old means it's dead if not used already. We have to realistic paths to a true PKI, both based on DNS: a) DNSSEC, b) the registries/registrars operate name-constrained (as least as anchors) CAs. That's it. The WebPKI offers little real security. Certificate transparency is just like DNSSEC -- it needs big deployment to be a win, and it's especially needed because we don't trust the CAs because there's so many because they are not name constrained. In DNSSEC the trust problem is still there, so CT could be applied to DNSSEC, but if you use QName minimization then it's harder for the root zone and TLDs to decide when to MITM you -- that's a really strong characteristic that PKIX couldn't hope to have because it doesn't have a directory. (Stapling DNSSEC chains in TLS would defeat this, but it is needed for last mile reasons, such as hotel networks.)
- tptacek 7y ago
  Nobody likes the WebPKI. But if you posted the private key for any trusted CA on Pastebin, it would be a very big deal. People around the world would get paged, and many of them would actually have to come in to work. Contrast that with DNSSEC. The root key for the entire Internet, the one they have the secret Stonecutters ceremony to establish, could end up on Pastebin tomorrow and nothing would happen. Nothing would happen the next day either. Weeks could elapse and nothing would happen. What's more, the comparison holds if you go back a year, 2 years, 10 years. The WebPKI is old (though evolving, unlike DNSSEC, for which things like transparency logs remain defensively evoked hypotheticals), but it has been important throughout it's life. Hell, the application of DNSSEC we're talking about here is subsidiary to the WebPKI --- it's simply making sure that mail servers speak WebPKI-secured TLS to each other!