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 =)
Then update /etc/resolv.conf with your DoH option or old legacy..
... Not a fan of DoH but it doesn't matter if I like it.
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.
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'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.
Why should anyone be discriminated against based on the size of their mail server?
They got little hands
And little eyes
And they walk around
Tellin' great big lies
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.
It doesn't remove the need for DNSSEC. Reading elsewhere in the RFC you find this gem: "the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades."
So, basically, you use MTA-STS to prevent malicious SMTP TLS downgrades, but it doesn't actually prevent malicious downgrades unless you use DNSSEC. At least everybody has an excuse, now, to add an HTTP client to their mail transfer agent. Plus, now you get to duplicate MX information in two places, DNS and the WWW, even though it would have been trivial to declare STARTTLS as required in the TXT record.