SMTP MTA Strict Transport Security (MTA-STS) | Hacker News Reader

SMTP MTA Strict Transport Security (MTA-STS)

tools.ietf.org

93 pointsokket39 comments

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!

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.

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.

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.

DNSSEC advocates also believe DANE is needed to address the weaknesses in things like HPKP and HSTS. Of course, nobody else does, no mainstream browser implements DANE, and at least two have attempted to support DANE and then withdrew that support.

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.

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.

Why should anyone be discriminated against based on the size of their mail server?

Small mail server people got no reason to live.

  They got little hands
  And little eyes
  And they walk around
  Tellin' great big lies

That's why.

But now we have dns over https too?

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 =)

Some sort of secure channel DNS seems likely to trickle down. Especially since an MTA is already well past getaddrinfo. And STS already requires https (which I do find kind of weird). So all the heavy lifting code of some form of secure DNS is here.

All it takes is someone updating the glibc resolver function to handle DoH.

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.

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

No changes are required in postfix yet? as it's just published expect updates from Postfix and Exim soon.

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... [2] https://pypi.org/project/postfix-mta-sts-resolver/ [3] https://github.com/Snawoot/postfix-mta-sts-resolver

Perfect, thanks!

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).

Is it official or still in process?

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.

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

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.

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. :)

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.

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.

Isn't that redundant with DANE TLSA records?

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

why flawed...

the tree structure and government participation?

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

i've never understood how any pinning of certs/ca can work after the "quantum insert" relevation from snowden?

sorry if asking stupid questions...

QUANTUM INSERT doesn't do anything an ordinary attacker couldn't do; the only difference is that NSA can effectively deploy the attack anywhere on the Internet, and an independent attacker has to fight their way to any particular vantage point. But that's a distinction that doesn't make much of a difference in protocol design.

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.

I guess DNS is doomed... =)

and we will have to start writing public keys on a distributed wall of TLDs

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

> NSA controls the DNSSEC roots.

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.

Yes, they clearly and obviously do.

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?

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

Reply on news.ycombinator.com