Comment by alwillis | Hacker News Reader

Comment by alwillis | Hacker News Reader

Parent Full thread

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

[2]: https://stats.dnssec-tools.org/#graphs

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).

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

[2]: https://www.knot-dns.cz

[3]: https://weberblog.net/dnssec-validation-with-unbound-on-a-ra...

I didn't realize I even had to make the case for DNSSEC being a tool for centralization. That seemed patently obvious to me. If it wasn't to you, well, here goes: DNSSEC is a tree-based PKI, a single one, for the whole Internet, whose irrevocable roots are controlled by world governments. It is the archetypical centralized system.

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.

It's an interesting thread. DNS security seems important, when the DNS cache poisoning vuln came out everyone was harping about how we need to secure the Internets! What happened?

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?

When Kaminsky's vulnerability was published it was mitigated by randomized ports almost immediately, and Dan Bernstein's DNS server --- which always randomized --- wasn't susceptible. In fact, Kaminsky's vulnerability is derivative (not to take anything away from it; it's authentically clever) of a line of cache poisoning vulnerabilities from 1997 --- that is to say, we had a dry run for it in the 1990s. Bernstein's response to the 1997 vulnerabilities was to fix his server; Vixie's response was to say "DNSSEC will fix this" and do nothing. A decade later and we saw which approach was correct: in a sense, DNSSEC caused the Kaminsky vulnerability.

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.

> because "Uncle Sam" has de jure control over the domain names you care about

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.)

Reply on news.ycombinator.com