
SMTP MTA Strict Transport Security (MTA-STS) - okket
https://tools.ietf.org/html/rfc8461
======
tptacek
The authors include Google, Yahoo, Comcast, and Microsoft --- basically the
core providers of Internet email.

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!

~~~
wahern
Per the RFC, MTA-STS policy "presence and current version are indicated by a
TXT record at the Policy Domain. [...] To discover if a recipient domain
implements MTA-STS, a sender need only resolve a single TXT record."

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.

~~~
tptacek
_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._

~~~
wahern
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.

~~~
tptacek
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.

~~~
wahern
> 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.

~~~
tptacek
If we agree on the positive argument I don't think we have to resolve the
normative one. I disagree with you on that, strongly, but do not expect to
persuade you.

------
markovbot
So, to set this up for my domain, I have to make a TXT record like this:

    
    
      _mta-sts.example.com.     TXT     "v=STSv1; id=20180928;"
    

Where id is just a unique identifier for the current version of the STS
policy, then I configure a webserver to respond to requests for [https://mta-
sts.example.com/.well-known/mta-sts.txt](https://mta-sts.example.com/.well-
known/mta-sts.txt) that looks like this:

    
    
      version: STSv1
      mode: testing
      mx: mx1.example.com
      mx: mx2.example.com
      max_age: 86400
    
    

Am I understanding this right?

Also, I use postfix to send email, does anyone know how I can make postfix use
these policies?

~~~
Snawoot
At this moment there are no MTA-STS support in postfix. But this thread [1] in
postfix-users mailing list suggests acceptable solution: use external policy
server for MTA-STS discovery. I have implemented such server: package on PyPI
[2], source on Github [3]. Works for me.

[1] [http://postfix.1071664.n5.nabble.com/MTA-STS-when-
td95086.ht...](http://postfix.1071664.n5.nabble.com/MTA-STS-when-td95086.html)
[2] [https://pypi.org/project/postfix-mta-sts-
resolver/](https://pypi.org/project/postfix-mta-sts-resolver/) [3]
[https://github.com/Snawoot/postfix-mta-sts-
resolver](https://github.com/Snawoot/postfix-mta-sts-resolver)

~~~
markovbot
Perfect, thanks!

------
Boulth
Wow, I'm glad that this is official now. Is there a list of providers
supporting MTA STS? I've seen Gmail has appropriate policy files and records
but I've never seen anyone hit mta-sts subdomain on my own domain (meaning no
one is checking it).

~~~
forapurpose
Is it official or still in process?

------
jcrites
Nice! MTA-STS is for the email space what HTTP Strict Transport Security
(HSTS) is for websites.

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.

~~~
amaccuish
I don't think so. You could probably try and correlate the originating
IP/subnet HTTPS policy request and subsequent SMTP connection.

------
technion
Is anyone aware of whether there was a reason the DNS entry didn't let you
specify a host. For example,

    
    
          _mta-sts.example.com.     TXT     "v=STSv1; id=20180928;host=mta-sts.example2.com"
    

I've got 15 domains on our mail service. Adding 15 DNS records isn't a big
deal. Having to host 15 different websites is a pain.

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.

~~~
md_
The premise (of authentication) is that the identity of the policy host is the
same as the identity of the @domain.

That is, if mail is sent to you@example.com, 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. :)

------
walrus01
If you run your own smtpd/MX and are not yet doing TLS1.2 for connections to
other mail servers, before enforcing _only_ TLS for MX-to-MX smtp traffic, a
good first step is to set up to opportunistically negotiate TLS. 95% of the
big mail senders (google, office365, etc) will negotiate TLS with your smtpd
and transfer that way.

You can use letsencrypt in standalone mode to get free, valid public CA-signed
certs for your mail server.

~~~
eigengrau
Self-signed will work just as well, since no MTA talking to you requires the
cert to be trusted (maybe DANE is required now in that case, but I was also
using self-signed before I set up DANE and peers would all use opportunistic
encryption.

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.

------
garaetjjte
Isn't that redundant with DANE TLSA records?

~~~
tptacek
The point is that (to a first approximation) nobody uses DNSSEC, which is
badly flawed, and MTA-STS doesn't rely on it.

~~~
pungur
why flawed...

the tree structure and government participation?

~~~
tptacek
[https://sockpuppet.org/blog/2015/01/15/against-
dnssec/](https://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
tialaramex
Maybe time to update your rant about DNSSEC.

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 3.2.2.4.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?

~~~
tptacek
There's a FAQ on this post, which I wrote in 2015, that answers your
objection.

