SMTP MTA Strict Transport Security (MTA-STS) • Hacker News Board

Re: SMTP MTA Strict Transport Security (MTA-STS)

#31

Post by tptacek » Sat, Sep 29, 2018, 1:11 AM UTC

thrownhwn wrote: post #27

tptacek wrote: post #24

Earlier quoted context omitted.

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 supers…

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

Re: SMTP MTA Strict Transport Security (MTA-STS)

#32

Post by microcolonel » Sat, Sep 29, 2018, 1:25 AM UTC

wahern wrote: post #5

tptacek wrote: post #3

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…

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…

Did I miss something that made MTA DNS resolvers a target of spoofing? I don't see how a vaguely properly administered datacentre/server room network has much risk of DNS spoofing.

If somebody is intercepting and modifying the traffic between your MTA and the authoritative DNS servers for your sending address, then I think you have far simpler attacks to worry about. Or maybe you have a recursive resolver which does not verify authority? Just configure it to check.

Also, MTA-STS is the sort of thing you can monitor: a sudden downgrade after previously having seen support for a particular destination is a red flag, as is a large volume of non-MTA-STS traffic.

Re: SMTP MTA Strict Transport Security (MTA-STS)

#33

Post by damm » Sat, Sep 29, 2018, 1:29 AM UTC

wahern wrote: post #19

tedunangst wrote: post #12

Earlier quoted context omitted.

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 resist…

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.

Re: SMTP MTA Strict Transport Security (MTA-STS)

#34

Post by damm » Sat, Sep 29, 2018, 1:30 AM UTC

markovbot wrote: post #14

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…

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

Re: SMTP MTA Strict Transport Security (MTA-STS)

#35

Post by walrus01 » Sat, Sep 29, 2018, 2:05 AM UTC

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.

Re: SMTP MTA Strict Transport Security (MTA-STS)

#36

Post by pvg » Sat, Sep 29, 2018, 2:07 AM UTC

gerdesj wrote: post #30

tptacek wrote: post #15

Earlier quoted context omitted.

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, f…

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

Re: SMTP MTA Strict Transport Security (MTA-STS)

#37

Post by forapurpose » Sat, Sep 29, 2018, 2:31 AM UTC

Boulth wrote: post #2

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?

Re: SMTP MTA Strict Transport Security (MTA-STS)

#38

Post by technion » Sat, Sep 29, 2018, 7:16 AM UTC

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.

Re: SMTP MTA Strict Transport Security (MTA-STS)

#39

Post by md_ » Sat, Sep 29, 2018, 2:03 PM UTC

technion wrote: post #38

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 m…

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

Re: SMTP MTA Strict Transport Security (MTA-STS)

#40

Post by eigengrau » Sat, Sep 29, 2018, 3:53 PM UTC

walrus01 wrote: post #35

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 you…

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.