SMTP MTA Strict Transport Security (MTA-STS)

Motivations are important, but your response does not address the technical issues brought up by the parent comment.

Initial discovery uses DNS, so wouldn't uncached hosts still be vulnerable to downgrade attacks without DNSSEC? MTA-STS seems to suffer from some of the same issues facing HPKP.

Except in the absence of DNSSEC it does not ensure transport security. An attacker positioned to perform a MITM of an SMTP session is also positioned to MITM DNS requests.

It's also worth mentioning that even if you skipped TXT querying and went straight to querying mta-sts.example.com, the attacker can just drop the A or AAAA record for mta-sts.example.com.

The only way to prevent this is to use DNSSEC, which can sign negative answers.

There is the benefit that if a policy is already cached the attack shouldn't work until expired. But much like SPF and similar issues, misconfigurations are so common I'd bet many transfer agents will still fail open if no TXT record is found (i.e. assume it's been disabled). In most organizations (and even small ones), the people or processes for managing DNS and e-mail are separate from WWW. With MTA-STS, when e-mail stops flowing people are going to have to check that their web sites (servers, proxies, etc) are setup properly. That's not at all obvious and will result in a lot of persistently broken systems. Senders are likely to put in mitigations because "it's not our fault" isn't always an acceptable answer.

Plus, if you can MITM you can just drop connections until the policy is expired. MTA's will cache for days; policies like these usually have expiration times on the order of minutes or hours so that one can quickly and easily fix broken configurations. The DNS TXT version + HTTP policy max_age is a very awkward mechanism. IT departments will not understand this stuff well enough to use it as intended. The wording in the RFC that policy max_age should be on the order of weeks is just them papering things over.

The whole thing sounds like they got mid way through a design predicated on using HTTP+TLS policies (the bright idea) before realizing how untenable things were, but stayed committed nonetheless.

The difference between your threat model and mine is that yours is based on concern for random people running small mail servers. I understand and respect that threat model, though I do not appreciate or really care about it.

On the other hand: I believe email is a technological dead end, and that we are not evolving towards an Internet with a more distributed email system, but with less distribution. I think that, from a utilitarian perspective, the only mail servers that matter are the ones that Google and its peers run, and that's the threat model I care about.

In my threat model, MTA-STS basically eliminates the concern DNSSEC/DANE addresses. Since your threat model includes rarely-used independently-operated servers (note that mine includes things like Fastmail and Proton!), servers that won't have cached assertions, MTA-STS is inadequate for your needs.

The problem I have with your argument is that to fix your problem, which is an extreme niche, you require the radical centralization of all cryptographic trust on the Internet into a tree-shaped PKI whose roots and trunks are controlled by world governments and whose technical underpinnings date back to the 1990s. Even if I was to stipulate that you had a point, DNSSEC wouldn't be a viable answer to it.

But that's a normative argument, and my point about DNSSEC being done is positive, not normative: deployment of MTA-STS is going to end DNSSEC. Not because I want it to (though I do) or because it should (though it should) but because it will: it drives a stake through the heart of the last truly motivating problem that DNSSEC was going to solve.

> I think that, from a utilitarian perspective, the only mail servers that matter are the ones that Google and its peers run, and that's the threat model I care about.

I'd be surprised if Google doesn't already enforce TLS for other big peers like Microsoft. In your universe, what do we need a broken standard for?

> you require the radical centralization of all cryptographic trust on the Internet into a tree-shaped PKI

Web PKI isn't radically centralized? It's worse than radically centralized, because you can break Web PKI by attacking the weakest CA.

> it drives a stake through the heart of the last truly motivating problem that DNSSEC was going to solve.

MTA-STS may give people cover to pretend they don't need DNSSEC. But make no mistake: it doesn't actually solve the problem.

It's interesting that technical opinions of DNSSEC have devolved into such irrational hatred that people will openly proclaim that fake security is better than actual, DNSSEC-provided security. Yes, DNSSEC is complex. Yes, it has issues with network privacy. But those arguments don't redeem MTA-STS, which is fundamentally broken.

Wake me when we have DNS over HTTPS for anything except web browsers. Plus, someone running an MTA is very likely running a recursive DNS server on the same network, if not the same machine, that uses UDP or TCP for upstream queries. Anyone positioned to MITM SMTP is likely positioned to MITM DNS.

EDIT: Ah, perhaps you meant that with DNS over HTTPS, MTAs will need an HTTP client anyhow. IMO the path of least resistance will be adding HTTPS, DNSSEC, or w'ever to machine-local resolver services. But point taken (whether earnest or sarcastic =)