4 ms·

it doesn't matter if you defeat DNSSEC, because nothing important relies on it. Not true. I would say secure email is something important and that relies on D

it doesn't matter if you defeat DNSSEC, because nothing important relies on it. Not true. I would say secure email is something important and that relies on DANE, which requires DNSSEC. Good video on this: https://youtu.be/BhvU19RJrPY https://youtu.be/BhvU19RJrPY DANE’s TLSA records is the only method available to ensure that email is always encrypted between hosts. Otherwise it’s too easy for someone to MITM a connection and downgrade the connection. And actual data on DNSSEC and DANE usage shows DANE usage is way up: https://stats.dnssec-tools.org/ https://stats.dnssec-tools.org/

tptacek 7y ago
There is so little confidence in DNSSEC's utility to secure email that all the major email providers banded together and created a new standard, MTA-STS, specifically to route around ever needing to use DNSSEC.
- alwillis 7y ago
  I doubt there’s a lack of confidence since DNSSEC/DANE is obviously handling tens of millions of email messages everyday. Since DANE gives you more than just email, it has the advantage right now.
  - tptacek 7y ago
    Since no major email provider uses it, and since they're the driving force behind a standard designed to avoid its use, I think the burden is on you to show that there's confidence in DNSSEC for email.
    - alwillis 7y ago
      It’s not DNSSEC for email; it’s DANE and TLSA for email. Postfix and Exim, the two most popular MTAa support DANE. I did post data showing that nearly 2 million email servers are using DANE and that number continues to increase.
      - tptacek 7y ago
        Why is it even remotely interesting that 2 pieces of open source software support a protocol? And why do I care that email forwarders run by registrars that automatically sign domains "support" DNSSEC? What matters is the percentage of all email that uses the protocol. Never use Exim, by the way.
- sneak 7y ago
  "nothing relies on it" and "there is not a majority consensus that it is valuable or useful" is not the same assertion. The first is both falsifiabile and demonstrably false. The second may well be true. Your opinion about the usefulness of DNSSEC is well-documented. That's not the topic of this specific thread: here we are discussing the theoretical case where the DNSSEC KSKs were copied to an unauthorized party, and what damage they may be able to wreak. As I mentioned, they could use it to forge DNSSEC responses to validating resolvers, now and in the future. It is a fact that some small number of people rely on DNSSEC responses today, so that would be the attack surface. If DNSSEC usage declines, as it seems you wish it does, then the consequence of such a leak of key material would also decline with that. If it increases, then the consequence of such a leak would also increase, as more people in that hypothetical future would be theoretically vulnerable to forged responses. If you're a group that steals high value keys for a living, it would be nice to steal the DNSSEC long-term keys when DNSSEC is small and unimportant, because it might be a lot more difficult later if DNSSEC becomes widely adopted to protect critical infrastructure. Already at least a few dozen people think that these keys are sufficiently important to spend thousands of dollars and dozens of valuable witness-hours traveling to these key ceremonies and storing these safes and whatnot. Perhaps they are entirely misguided and should abandon the entire endeavor. I don't think the "DNS TLDs are simply a proxy for governments" is enough of a disqualifying argument when several governments or even large corporations have implicitly trusted CAs in widespread use. I think it's useful to have another choice of validated data to cross-check with. Perhaps you are worried that it would de facto replace the existing corporate-managed PKI with a government-managed one entirely? I also think that what another commenter mentioned, that you have a choice in governments (and could theoretically publish your signed certificate data in multiple zones, controlled by multiple different governments) is an extremely beneficial set of possibilities. Multiple-TLD-publishing is certainly a better system than the attempts at public-key pinning and observatories/transparency we've seen as attempts to solve the "anyone can issue for any domain" problem as it stands. ...unless, of course, the root zone KSKs get stolen. Then all the TLD zones are unsafe. :)
  - tptacek 7y ago
    If "nothing relies on it" is demonstrable false, falsify it. The root keys appear on Pastebin tomorrow. Tell me what breaks.
- alwillis 7y ago
  The real story is that for Google, Microsoft, and Yahoo, among others, there are infrastructural reasons they can't easily support DNSSEC; it’s a problem these guys have because of how they’ve architected their global email infrastructure, etc. However, MTA-STS has its own issues: [1] * Still can and should prefer DANE outbound * Authenticates domain control via CA leap of faith * Vulnerable to MiTM at cert bootstrap * Vulnerable to weakest root CA, and unauthorized certs * Open to downgrade on first (or irregular) contact * Complex mix of HTTPS, unsigned DNS and SMTP Given these caveats, I'd say to Google, Microsoft and the rest: good luck with that. All standards are about tradeoffs; even though MTA-STS isn’t as good or as battle-tested as DANE’s TLSA, it’s something they can implement fairly quickly versus what it would take to rearchitect so they could do DNSSEC/DANE properly. I suspect if they were able to start over, they’d do something differently, but it is what it is. We shouldn’t be too surprised; DNSSEC implements a distributed chain of trust and that doesn’t work with the increasingly centralized systems the largest email providers run. It has nothing to do with a lack of confidence in DNSSEC and DANE since we already know about the nearly 2 million domains with signed MX and DANE records and the over 5000 domains hosting DANE mail servers: [2] [1]: https://youtu.be/A8SgW9y__io?t=5875 https://youtu.be/A8SgW9y__io?t=5875 [2]: https://stats.dnssec-tools.org/#graphs https://stats.dnssec-tools.org/#graphs
  - tptacek 7y ago
    It's literally among the first words of the spec: MTA-STS was designed because providers don't want to use DNSSEC. Those aren't tea leaves I'm reading; they actually wrote it in the spec. I don't know what this "centralization" argument is. One of the biggest centralizers on the Internet, Cloud Flare, is the only proponent of DNSSEC among the tech companies (DNSSEC is a tool for centralization; it's difficult and expensive to manage, so people will pay to have Cloud Flare do it for them, and Cloud Flare knows that).
    - alwillis 7y ago
      It's literally among the first words of the spec: MTA-STS was designed because providers don't want to use DNSSEC. Those aren't tea leaves I'm reading; they actually wrote it in the spec. 1. Funny, my version of the spec says something different: The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation. DNSSEC is a tool for centralization; it's difficult and expensive to manage, so people will pay to have Cloud Flare do it for them, and Cloud Flare knows that The point you conveniently missed is that MTA-STS was developed to address a problem that only large, centralized email providers have. They would use DNSSEC/DANE if they could, but they can't, so they created something else that's not as good. You also didn't address the security problems MTA-STS has, but I guess I’m not surprised. Cloudflare and Google Cloud [1] offer DNSSEC as yet another feature for their hosting services--that's no different than any of the other technologies and services they offer. I’m sure they see providing DNSSEC as a convenience and a competitive advantage. Saying DNSSEC is a tool for centralization because of Cloudflare is like saying email is a tool for centralization because of Gmail. Lots of organizations that deal with domain registration, running TLD servers and other parts of the internet infrastructure are publically advocating for DNSSEC but that's mostly behind the scenes stuff: ISC, ICANN, Verisign, NANOG, etc. As the tools mature, deploying DNSSEC-signed zones gets easier. Automatic zone signing and key rollover are built into DNS software like BIND, PowerDNS and Knot DNS [2] these days, so it doesn't have to be that big of a deal for most organizations. It literally takes 10 minutes to enable Unbound’s (which many Linux and BSD distros ship as their default DNS resolver) DNSSEC validation feature. You can put Unbound on a Raspberry Pi and have it be the DNSSEC validating resolver for your home network. [3] [1]: https://cloud.google.com/dns/docs/dnssec https://cloud.google.com/dns/docs/dnssec [2]: https://www.knot-dns.cz https://www.knot-dns.cz [3]: https://weberblog.net/dnssec-validation-with-unbound-on-a-raspberry/ https://weberblog.net/dnssec-validation-with-unbound-on-a-ra...

tptacek 7y ago

There is so little confidence in DNSSEC's utility to secure email that all the major email providers banded together and created a new standard, MTA-STS, specifically to route around ever needing to use DNSSEC.

alwillis 7y ago
I doubt there’s a lack of confidence since DNSSEC/DANE is obviously handling tens of millions of email messages everyday. Since DANE gives you more than just email, it has the advantage right now.
- tptacek 7y ago
  Since no major email provider uses it, and since they're the driving force behind a standard designed to avoid its use, I think the burden is on you to show that there's confidence in DNSSEC for email.
  - alwillis 7y ago
    It’s not DNSSEC for email; it’s DANE and TLSA for email. Postfix and Exim, the two most popular MTAa support DANE. I did post data showing that nearly 2 million email servers are using DANE and that number continues to increase.
    - tptacek 7y ago
      Why is it even remotely interesting that 2 pieces of open source software support a protocol? And why do I care that email forwarders run by registrars that automatically sign domains "support" DNSSEC? What matters is the percentage of all email that uses the protocol. Never use Exim, by the way.
sneak 7y ago
"nothing relies on it" and "there is not a majority consensus that it is valuable or useful" is not the same assertion. The first is both falsifiabile and demonstrably false. The second may well be true. Your opinion about the usefulness of DNSSEC is well-documented. That's not the topic of this specific thread: here we are discussing the theoretical case where the DNSSEC KSKs were copied to an unauthorized party, and what damage they may be able to wreak. As I mentioned, they could use it to forge DNSSEC responses to validating resolvers, now and in the future. It is a fact that some small number of people rely on DNSSEC responses today, so that would be the attack surface. If DNSSEC usage declines, as it seems you wish it does, then the consequence of such a leak of key material would also decline with that. If it increases, then the consequence of such a leak would also increase, as more people in that hypothetical future would be theoretically vulnerable to forged responses. If you're a group that steals high value keys for a living, it would be nice to steal the DNSSEC long-term keys when DNSSEC is small and unimportant, because it might be a lot more difficult later if DNSSEC becomes widely adopted to protect critical infrastructure. Already at least a few dozen people think that these keys are sufficiently important to spend thousands of dollars and dozens of valuable witness-hours traveling to these key ceremonies and storing these safes and whatnot. Perhaps they are entirely misguided and should abandon the entire endeavor. I don't think the "DNS TLDs are simply a proxy for governments" is enough of a disqualifying argument when several governments or even large corporations have implicitly trusted CAs in widespread use. I think it's useful to have another choice of validated data to cross-check with. Perhaps you are worried that it would de facto replace the existing corporate-managed PKI with a government-managed one entirely? I also think that what another commenter mentioned, that you have a choice in governments (and could theoretically publish your signed certificate data in multiple zones, controlled by multiple different governments) is an extremely beneficial set of possibilities. Multiple-TLD-publishing is certainly a better system than the attempts at public-key pinning and observatories/transparency we've seen as attempts to solve the "anyone can issue for any domain" problem as it stands. ...unless, of course, the root zone KSKs get stolen. Then all the TLD zones are unsafe. :)
- tptacek 7y ago
  If "nothing relies on it" is demonstrable false, falsify it. The root keys appear on Pastebin tomorrow. Tell me what breaks.
alwillis 7y ago
The real story is that for Google, Microsoft, and Yahoo, among others, there are infrastructural reasons they can't easily support DNSSEC; it’s a problem these guys have because of how they’ve architected their global email infrastructure, etc. However, MTA-STS has its own issues: [1] * Still can and should prefer DANE outbound * Authenticates domain control via CA leap of faith * Vulnerable to MiTM at cert bootstrap * Vulnerable to weakest root CA, and unauthorized certs * Open to downgrade on first (or irregular) contact * Complex mix of HTTPS, unsigned DNS and SMTP Given these caveats, I'd say to Google, Microsoft and the rest: good luck with that. All standards are about tradeoffs; even though MTA-STS isn’t as good or as battle-tested as DANE’s TLSA, it’s something they can implement fairly quickly versus what it would take to rearchitect so they could do DNSSEC/DANE properly. I suspect if they were able to start over, they’d do something differently, but it is what it is. We shouldn’t be too surprised; DNSSEC implements a distributed chain of trust and that doesn’t work with the increasingly centralized systems the largest email providers run. It has nothing to do with a lack of confidence in DNSSEC and DANE since we already know about the nearly 2 million domains with signed MX and DANE records and the over 5000 domains hosting DANE mail servers: [2] [1]: https://youtu.be/A8SgW9y__io?t=5875 https://youtu.be/A8SgW9y__io?t=5875 [2]: https://stats.dnssec-tools.org/#graphs https://stats.dnssec-tools.org/#graphs
- tptacek 7y ago
  It's literally among the first words of the spec: MTA-STS was designed because providers don't want to use DNSSEC. Those aren't tea leaves I'm reading; they actually wrote it in the spec. I don't know what this "centralization" argument is. One of the biggest centralizers on the Internet, Cloud Flare, is the only proponent of DNSSEC among the tech companies (DNSSEC is a tool for centralization; it's difficult and expensive to manage, so people will pay to have Cloud Flare do it for them, and Cloud Flare knows that).
  - alwillis 7y ago
    It's literally among the first words of the spec: MTA-STS was designed because providers don't want to use DNSSEC. Those aren't tea leaves I'm reading; they actually wrote it in the spec. 1. Funny, my version of the spec says something different: The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation. DNSSEC is a tool for centralization; it's difficult and expensive to manage, so people will pay to have Cloud Flare do it for them, and Cloud Flare knows that The point you conveniently missed is that MTA-STS was developed to address a problem that only large, centralized email providers have. They would use DNSSEC/DANE if they could, but they can't, so they created something else that's not as good. You also didn't address the security problems MTA-STS has, but I guess I’m not surprised. Cloudflare and Google Cloud [1] offer DNSSEC as yet another feature for their hosting services--that's no different than any of the other technologies and services they offer. I’m sure they see providing DNSSEC as a convenience and a competitive advantage. Saying DNSSEC is a tool for centralization because of Cloudflare is like saying email is a tool for centralization because of Gmail. Lots of organizations that deal with domain registration, running TLD servers and other parts of the internet infrastructure are publically advocating for DNSSEC but that's mostly behind the scenes stuff: ISC, ICANN, Verisign, NANOG, etc. As the tools mature, deploying DNSSEC-signed zones gets easier. Automatic zone signing and key rollover are built into DNS software like BIND, PowerDNS and Knot DNS [2] these days, so it doesn't have to be that big of a deal for most organizations. It literally takes 10 minutes to enable Unbound’s (which many Linux and BSD distros ship as their default DNS resolver) DNSSEC validation feature. You can put Unbound on a Raspberry Pi and have it be the DNSSEC validating resolver for your home network. [3] [1]: https://cloud.google.com/dns/docs/dnssec https://cloud.google.com/dns/docs/dnssec [2]: https://www.knot-dns.cz https://www.knot-dns.cz [3]: https://weberblog.net/dnssec-validation-with-unbound-on-a-raspberry/ https://weberblog.net/dnssec-validation-with-unbound-on-a-ra...