https://mail.sys4.de/pipermail/dane-users/2020-February/0005...
BTW: the US is #2 in the world in terms of DANE-enabled email hosts.
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
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/
Since DANE gives you more than just email, it has the advantage right now.
I did post data showing that nearly 2 million email servers are using DANE and that number continues to increase.
Never use Exim, by the way.
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. :)
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
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]
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).
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.
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
[3]: https://weberblog.net/dnssec-validation-with-unbound-on-a-ra...
The "security problems" you raised with MTA-STS all boil down to "doesn't use DNSSEC, like I want it to" (in fact, that's literally the first security problem you raised, though all the "relies on the WebPKI" points say the same thing as well).
It is not surprising or interesting to me that DNS operators are excited about DNSSEC. But, obviously, the fact that no tech company other than Cloud Flare has adopted it refutes the argument that network and security engineers are accepting it. The opposite thing is true: the protocol has been categorically rejected, and is moribund.
I'll keep going with this thread if you want, but you should be aware that we are the only two people reading it.
DoH or DoT is nice, at least you can pick your poison, if you will, by picking your resolver, but they are still just feeding you whatever they got from auth resolvers around the world via whatever packets they happen to have received.
Sure, then use TLS as the next step. And that might work if browsers and the CA/B gets serious, but who knows, there are still nation state CAs everywhere by default.
Wouldn't it be easier to set up DNSSEC and a lot of Cert Transp style notaries that can catch Uncle Sam and the 4 other eyes in the act?
You can't use DNSSEC to "catch Uncle Sam in the act", because "Uncle Sam" has de jure control over the domain names you care about. What's worse, Certificate Transparency actually has caught misissuing CAs, and the consequences for those CAs has been lethal: Chrome and Mozilla put the largest commercial CA on the Internet out of business over misissuance. When CA's misbehave, we can revoke them. We can't do that with DNSSEC: when .COM misbehaves --- and it will, we know, because it already has --- we remain stuck with it. The DNS is absolutely not trustworthy enough to store keys.
I know, and that's okay, if we knew what are those actual actions, and were there a log of those people could decide what to do.
To me this sounds like an opportunity to decentralize DNSSEC, skip ICANN, let TLDs pick "trust root providers", make it tamper evident, and the resolvers will maintain the trusted set of roots.
Or not, and just don't put keys into DNS and learn to live with the additional network round-trips required for the workarounds. :( (Like MTA-STS, which, on the other hand, is great. Relatively easy to deploy, opt-in, has a time-lock like HSTS, so sort of resilient. But still a workaround.)