What's interesting about MTA-STS is its motivation: it's an effort to ensure TLS between MTAs without relying on DNSSEC. SMTP was one of the few remaining Internet security gaps DNSSEC purported to fill, and the IETF has now for the most part worked around that gap.
I think adoption of MTA-STS --- a foregone conclusion, I think, given its sponsors --- is basically the end of DNSSEC. Thankfully!
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.
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.
_mta-sts.example.com. TXT "v=STSv1; id=20180928;"
Also, I use postfix to send email, does anyone know how I can make postfix use these policies?
This RFC has been around for a bit, and if I understand correctly was recently moved to the status "Proposed Standard" from "Internet-Draft".
I'm glad to see email security continuing to move forward. Thank you to the people who put what was undoubtedly considerable time into making this a reality.
Question to those who are more knowledgeable: Is there a way to determine whether a particular inbound connection is respecting a domain's MTA-STS policy? It'd be nice to be able to monitor what percent of incoming connections are MTA-STS aware, as a way to measure adoption.
_mta-sts.example.com. TXT "v=STSv1; id=20180928;host=mta-sts.example2.com"
I know someone will say "Just use S3 it's easy" but doing 15 times is an annoyance, it feels like an obviously missing feature to allow consolidation.
Edit: Section 8.2 describes using a CNAME to achieve this effect. But it also involves running reverse proxies and similar efforts.
That is, if mail is sent to firstname.lastname@example.org, the certificate presented by whatever host is serving the policy must be valid for example.com.
So even if the TXT record functioned as you describe, mta-sts.example2.com would have to have a cert valid for example.com. Of course it could provide a single cert with SANs valid for all example*.coms that you run, but such a setup would preclude using SNI to serve the "correct" cert.
tl;dr: fetchers have to talk to "example.com" so that the HTTPS server knows what cert to present, and the cert has to match "example.com" so senders know the host is actually authenticated.
Regarding your comment on reverse proxies, it's actually quite easy to setup an HTTPS server that proxies some hosting org's policy but uses Let's Encrypt to fetch the proper cert for your domain. I did this for mine in about 50 lines of Go. Not saying I'd trust this for some production setup, but it's really quite easy. :)
You can use letsencrypt in standalone mode to get free, valid public CA-signed certs for your mail server.
letsencrypt is a bit cumbersome if you want to support DANE, at least if you don’t run your own DNS or have an API to your provider’s DNS.
the tree structure and government participation?
For example, when you're explaining about how DNSSEC isn't relevant to the Domain Validation problem, you could mention that er, it's checked by the CA which issued your certificate, and closes literally the only otherwise insecure link in the chain for that CA.
Sound implementations of 18.104.22.168.7 (including those by your own chosen CA) are protected by DNSSEC. No DNSSEC? No protection.
Further down you're going to want to cover how the thing you were so sure it was essential to protect (secret hostnames) is actually gone now in the very architecture you told everybody they should prefer over DNSSEC (the Web PKI). If you're polite you'd explain how this happened, all the trust breaches and security problems in your better option that meant we had no other choice.
Or you know, just keep linking to the 2015 version and acting as though nothing changed. Put it on your Friendster maybe?
sorry if asking stupid questions...
Importantly: if NSA is part of your threat model, the hoped-for alternative that STS supersedes --- DNSSEC --- is no help. NSA controls the DNSSEC roots.
Is this any more true than saying "NSA controls the web CA roots" i.e. the NSA could infiltrate one of the hundreds of certificate authorities that browsers trust and issue a malicious certificate?
If so, and if NSA is part of your threat model, then I would say that STS doesn't help very much either.
What's more interesting is the issue of transparency. Are STS clients going to be requiring that the certificates for the HTTPS resources they access are present in a certificate transparency log? CAs are allowed to issue certificates that aren't logged, for privacy reasons I suppose, but there would be no such excuse for a "DNS transparency" log of DNSSEC keys for top level domains. Logging all of these keys would be orders of magnitude simpler than logging all CA issued certificates on the web.
No they don’t. You know better than to spread FUD, regardless of what you think about DNSSEC.
I agree with your other points, however.
and we will have to start writing public keys on a distributed wall of TLDs