This is super interesting, and with Let’s Encrypt doing DNS based authorizations, such that legitimate certs can be generated for free, and the majority of users don’t do cert pinning (due in part to the fact that we trust CAs, for better or for worse, and cert rotations being more and more common….), this sort of thing is bound to be super super duper fun next time.
Deploy DNSSEC signing for your zones. It won’t protect everyone, but it rewards the behavior you want to reward: systems behind verifying resolvers will be protected from these shenanigans. If PKIX issuers aren’t using validating resolvers before issuing DNS-proven certs, then that’s a security failure on their part.
If you’re in a position to do so, ask your network provider where they are on using ROA verification for routes, as part of RPKI security. My colo box is hosted with people who’ve been filtering on this basis for a few years now. This is no longer new functionality and we’re reaching the point where we’re in danger of the lawyers getting involved to argue gross negligence if operators aren’t filtering out provably bad route advertisements.
“Reminder: you could publish the DNSSEC root RSA secret keys on Pastebin and nothing on the Internet that matters would break.”
edit: oh I forgot about this gem
“Overlooking some DNSSEC outages because they’re so frequent: By default, Unbound ignores for up to 24 hours any DNSSEC failure resulting from expired RRSIGs.”
Let what die? DNSSEC? It’s at over 50% of all .NL domains and generally on an upwards trend. The number of mail-systems being protected with DANE (TLSA records in DNSSEC-signed domains) is ever-increasing, since the only alternative for MX delivery is MTA-STS (spec still in draft, has gone through incompatible changes, and bakes in the same failure modes which led us to reject TLSA Usages 0 and 1 for DANE/SMTP).
Every Internet technology ever has led to outages in the early days of deployment, until people figured out how to make tools more robust … and even then has led to reductions in the frequency of outages, not to eliminating them. The questions are “what’s the failure mode?” and “will things improve?”. We see enough outages on a per-domain basis caused by inept management of DNS itself, without DNSSEC, that I don’t see DNSSEC as moving the needle on outage frequency here.
I do see more folks outsourcing their DNS management (eg, AWS Route 53, CloudFlare) and as we’ve seen from CloudFlare’s DNSSEC support, this pays off in getting professionally managed DNS+DNSSEC by people who understand it.
The Internet is full of sites which enumerate mistakes and try to say that the existence of mistakes by individuals means the technology should die. Finding one website which does this for DNSSEC does not mean that DNSSEC is dying.
Oh, and I agree that DNSSEC is ugly and problematic, but for verifying authenticity of name resolution, it’s the only solution we’ve got today. So today, it’s what we deploy. Let’s not abandon something which works, just because it’s not perfect.
I am very annoyed because I wrote a 3 page rebuttal to every point and accidentally force closed my browser when switching apps.
tl;dr it’s a dead RFC from 1997. Its usage is measurably on the decline. We peaked at ~1% of the important domains (net com and org).
They tried to use DANE for IRC and nobody wanted it. They removed DANE code from Irssi.
DANE for SMTP is a poor argument with the existence of LetsEncrypt. This argument is so tired I don’t know why it persists.
If you can convince Green, Ptacek, Bernstein, or Marlinspike that DNSSEC is worth having I will rescind my statements. But it’s not going to happen. It’s awful, adds vulnerabilities to DNS resolvers, and has too many failure modes which are completely opaque to end users/applications.
DNSSEC is basically Wayne’s ex-girlfriend Stacy. “It’s over. Get the net!”
If you want security here’s what you do: you use dnscrypt or equivalent to a large provider like OpenDNS. They have the means to actively monitor for cache poisoning and other attacks worldwide in real-time. Voila, you know your DNS isn’t being tampered with.
For browsers/HTTPS, we have a semi-working model now without DNSSEC. I can’t speak authoritatively to the trade-offs which apply there.
SMTP I can speak authoritatively on: I added the initial DNSSEC support to Exim (although Jeremy Harris later picked it up and did the bulk of the work to take it to full DANE support) and talked extensively with Viktor Dukhovni of Postfix on the DANE spec, refining the text which became the RFCs.
For Submission/Submissions service, or smarthost identity configuration, Let’s Encrypt is a sufficient answer.
For MX delivery, LE buys you nothing. For TLS security, you need an identity which you can verify. That identity can not be derived by insecure means. With email to MX, that means the only verifiable identity is the domain. The mail-domain is rarely in the certificate SAN list. To fix this, you need a way to map from the domain to a host identity, securely. Further, it needs to be done in such a way that one external domain important to your organization (“when the CEO starts shouting about mail not going through”) can’t force domains into your trust-store for use with all other domains. This is why DANE for SMTP prohibits TLSA Usage fields 0 and 1. This is one of the severe flaws in MTA-STS.
My current recommendation for MTA security for MX hosts is to get a Let’s Encrypt cert, setup DANE referencing that, and also set up the MTA-STS publishing side to let senders such as Gmail work, IF you’re willing to keep tracking the MTA-STS drafts for further breaking changes. This is what I set up for exim.org and for some of my own domains.
Thus Let’s Encrypt solves absolutely nothing for MX SMTP.
“If you want security” … I say that you first need to break down what you mean by “security” and who “you” is. When it comes to DNS, there’s authenticity and there’s privacy. dnscrypt provides privacy between you and whomever you talk to, as does DNS-over-HTTPS and DNS-over-TLS. dnscrypt does not provide any protection against tampering, whether at the resolver provider (under court order) or between them and the upstream.
If “you” is an end-user or home operator, then you can carefully pick a DNS resolver and choose one who don’t actively tamper with the results for profit (and where you trust the jurisdiction, etc), then using an external provider with very-local-to-you resolvers, or with client-subnet support, pays off and gets you fast easy wins and is usually worth doing. If you pick one which does DNSSEC validation for you and has privacy/integrity between you and them, then you’re in a strong position. Google, CloudFlare, censurfridns, Verisign Labs, these are decent choices.
If you’re a mail-server operator with bulk DNS traffic, that’s less tenable. There’s a reason that for decades now it’s been best practice for MTA operators for domains handling any non-trivial traffic to have a local resolver, either on-subnet or on-host. Thus the large external providers don’t help.
This is super interesting, and with Let’s Encrypt doing DNS based authorizations, such that legitimate certs can be generated for free, and the majority of users don’t do cert pinning (due in part to the fact that we trust CAs, for better or for worse, and cert rotations being more and more common….), this sort of thing is bound to be super super duper fun next time.
Please stop. DNSSEC is not a solution. Let it die already.
https://ianix.com/pub/dnssec-outages.html
“Reminder: you could publish the DNSSEC root RSA secret keys on Pastebin and nothing on the Internet that matters would break.”
edit: oh I forgot about this gem
“Overlooking some DNSSEC outages because they’re so frequent: By default, Unbound ignores for up to 24 hours any DNSSEC failure resulting from expired RRSIGs.”
Let what die? DNSSEC? It’s at over 50% of all .NL domains and generally on an upwards trend. The number of mail-systems being protected with DANE (TLSA records in DNSSEC-signed domains) is ever-increasing, since the only alternative for MX delivery is MTA-STS (spec still in draft, has gone through incompatible changes, and bakes in the same failure modes which led us to reject TLSA Usages 0 and 1 for DANE/SMTP).
Every Internet technology ever has led to outages in the early days of deployment, until people figured out how to make tools more robust … and even then has led to reductions in the frequency of outages, not to eliminating them. The questions are “what’s the failure mode?” and “will things improve?”. We see enough outages on a per-domain basis caused by inept management of DNS itself, without DNSSEC, that I don’t see DNSSEC as moving the needle on outage frequency here.
I do see more folks outsourcing their DNS management (eg, AWS Route 53, CloudFlare) and as we’ve seen from CloudFlare’s DNSSEC support, this pays off in getting professionally managed DNS+DNSSEC by people who understand it.
The Internet is full of sites which enumerate mistakes and try to say that the existence of mistakes by individuals means the technology should die. Finding one website which does this for DNSSEC does not mean that DNSSEC is dying.
Oh, and I agree that DNSSEC is ugly and problematic, but for verifying authenticity of name resolution, it’s the only solution we’ve got today. So today, it’s what we deploy. Let’s not abandon something which works, just because it’s not perfect.
I am very annoyed because I wrote a 3 page rebuttal to every point and accidentally force closed my browser when switching apps.
tl;dr it’s a dead RFC from 1997. Its usage is measurably on the decline. We peaked at ~1% of the important domains (net com and org).
They tried to use DANE for IRC and nobody wanted it. They removed DANE code from Irssi.
DANE for SMTP is a poor argument with the existence of LetsEncrypt. This argument is so tired I don’t know why it persists.
If you can convince Green, Ptacek, Bernstein, or Marlinspike that DNSSEC is worth having I will rescind my statements. But it’s not going to happen. It’s awful, adds vulnerabilities to DNS resolvers, and has too many failure modes which are completely opaque to end users/applications.
DNSSEC is basically Wayne’s ex-girlfriend Stacy. “It’s over. Get the net!”
https://youtu.be/RJRvPmONjVY
If you want security here’s what you do: you use dnscrypt or equivalent to a large provider like OpenDNS. They have the means to actively monitor for cache poisoning and other attacks worldwide in real-time. Voila, you know your DNS isn’t being tampered with.
For browsers/HTTPS, we have a semi-working model now without DNSSEC. I can’t speak authoritatively to the trade-offs which apply there.
SMTP I can speak authoritatively on: I added the initial DNSSEC support to Exim (although Jeremy Harris later picked it up and did the bulk of the work to take it to full DANE support) and talked extensively with Viktor Dukhovni of Postfix on the DANE spec, refining the text which became the RFCs.
For Submission/Submissions service, or smarthost identity configuration, Let’s Encrypt is a sufficient answer.
For MX delivery, LE buys you nothing. For TLS security, you need an identity which you can verify. That identity can not be derived by insecure means. With email to MX, that means the only verifiable identity is the domain. The mail-domain is rarely in the certificate SAN list. To fix this, you need a way to map from the domain to a host identity, securely. Further, it needs to be done in such a way that one external domain important to your organization (“when the CEO starts shouting about mail not going through”) can’t force domains into your trust-store for use with all other domains. This is why DANE for SMTP prohibits TLSA Usage fields 0 and 1. This is one of the severe flaws in MTA-STS.
My current recommendation for MTA security for MX hosts is to get a Let’s Encrypt cert, setup DANE referencing that, and also set up the MTA-STS publishing side to let senders such as Gmail work, IF you’re willing to keep tracking the MTA-STS drafts for further breaking changes. This is what I set up for exim.org and for some of my own domains.
Thus Let’s Encrypt solves absolutely nothing for MX SMTP.
“If you want security” … I say that you first need to break down what you mean by “security” and who “you” is. When it comes to DNS, there’s authenticity and there’s privacy. dnscrypt provides privacy between you and whomever you talk to, as does DNS-over-HTTPS and DNS-over-TLS. dnscrypt does not provide any protection against tampering, whether at the resolver provider (under court order) or between them and the upstream.
If “you” is an end-user or home operator, then you can carefully pick a DNS resolver and choose one who don’t actively tamper with the results for profit (and where you trust the jurisdiction, etc), then using an external provider with very-local-to-you resolvers, or with client-subnet support, pays off and gets you fast easy wins and is usually worth doing. If you pick one which does DNSSEC validation for you and has privacy/integrity between you and them, then you’re in a strong position. Google, CloudFlare, censurfridns, Verisign Labs, these are decent choices.
If you’re a mail-server operator with bulk DNS traffic, that’s less tenable. There’s a reason that for decades now it’s been best practice for MTA operators for domains handling any non-trivial traffic to have a local resolver, either on-subnet or on-host. Thus the large external providers don’t help.