Hacker News Reader

Comment by tptacek | Hacker News Reader

This is great news. It's worth noting: the subtext behind MTA-STS (actually made explicit at one point in the RFC) is that it works without DNSSEC and DANE, which major mail providers weren't adopting (for good reason).

Since breaking SMTP TLS MITM was one of the few remaining things DNSSEC could help with that didn't have answers in other protocols, this is a major blow to any impetus to roll DNSSEC out in the future. Between MTA-STS, DNS-over-HTTPS/TLS, and certificate transparency, I think DNSSEC is essentially moribund now.

View on HN

MTA-STS is a Trust on First Use protocol (for those who has not read the RFC, check section "10. Security Considerations"). DANE with DNSSEC is not.

The benefits and drawbacks of TOFU is well known, and ssh is one where most administrators first get a feel for it. In this case however we don't even have any human validation, so it is blind trust on first use. Maybe future version of popular email servers will hardcode a initial certificate or policy for gmails and other major email provider, but that would be beyond the scope of MTA-STS.

The same people who push DANE and DNSSEC yesterday will continue to do it tomorrow. Adding caching and policy to starttls is good, and for major email provider the first use will be done once and a valid version will effectively remain in the cache forever since normal daily use will keep it up to date. This scenario might not be as applicable to say a lawyer firm who for security reasons run their own email server, where a larger potential number of cases the initial email is the first time one email server connect to the other.

The advantage of key continuity (the better term than "TOFU") over top-down PKI is that key continuity works at scale, and PKI does not. As you note: key continuity schemes admit to straightforward enhancements, like preload registries, that PKIs don't.

I don't really want to go too far down this rabbit hole, but if a lawyer firm came to us for advice and told us they run their own mail server "for security reasons", we would tell them for security reasons to stop doing that.

Yes, people will continue advocating for and noodling around with DNSSEC, the same way they do with PGP key servers and custom cipher cascades. But that's not the test for whether a technology is successful --- at least not these kinds of technologies. It is looking less and less likely --- I'd say we're past the event horizon now --- that DNSSEC will ever be a mainstream component of the Internet security model.

We have had a similar protocol for TOFU on the web for a very long time called HTTP Public Key Pinning, and it did nothing to deprecate PKI. It is a bit telling that google actually removed HTTP Public Key Pinning in 2017 from chrome.

I can't speculate if DNSSEC can continue grow or will fall in use in some unspecified future, but I suspect that a TOFU version of key pinning for email server won't be the death knell. If it work it is because the wast majority of email traffic is located in basically a handful of companies, which is why the wast majority of domain owners won't notice a difference. I would assume Microsoft already pins the certificate of Google servers and vice verse.

I'm not saying that global key continuity schemes always work, only that they have worked (SSH is the best-known example), where global PKI schemes have never once worked.

Late edit:

But note: Google didn't follow up the deprecation of HPKP by promoting DANE. Rather: CT is working, and given that, HPKP wasn't worth the hassle. CT doesn't depend on DNSSEC either!

>(SSH is the best-known example), where global PKI schemes have never once worked.

I’ve seen PKI work for SSH in $large-gov-branch. It works just fine but it requires a cert infra most orgs don’t want.

PKIs certainly work in enterprise settings.

If we look at gmail's current policy: version: STSv1 mode: testing mx: gmail-smtp-in.l.google.com mx: *.gmail-smtp-in.l.google.com max_age: 86400

Then if somebody can take over the domain google.com they immediately start receiving mail for gmail.com. If you can take over gmail.com you may have to wait for a day.

The classical argument against DNSSEC (the governments are in control) applies just as much to MTA-STA.

In theory, there is RFC 7929 and RFC 8162 [PGP and S/MIME keys over DANE], but I don't think DNS is the best way to expose that information. I also don't think anyone (important) actually supports these mechanisms to retrieve public keys.

Why is there no love for DNSSEC and DANE?

Google [against dnssec].

Reply on news.ycombinator.com