SMTP Strict Transport Security [LWN.net]

SMTP Strict Transport Security

Posted Apr 21, 2016 7:21 UTC (Thu) by fredrik (subscriber, #232)
Parent article: SMTP Strict Transport Security

Why not instead revive SMTPS, TLS-wrapped SMTP over port 465, again? The regular TLS certificate trust infrastructure for HTTPS, or DANE, could then be reused to secure email delivery too.

It seems a waste to use a legacy clear text protocol solely for the purpose to upgrade with STARTTLS, when you can just as well initiate TLS immediately on first connect.

I'm sure that if the big players agreed to use SMTPS by default, and deploy a HTST-like solution to deprecate the use of the regular port 25, the internet as a community could obsolete a clear text, downgrade and MIM attack vulnerable infrastructure in a few years.

I wouldn't have thought a large shift proposal like that was possible a few years ago. Through recent years trend to migrate to HTTPS by default on most big services, HTST, HTTP/2 being TLS mostly, and Lets encrypt, we've seen that better standards can be introduced very quickly when the big players agree on sensible non-proprietary solutions and lead the way.

Aside from that I'm happy to see that DANE is included in the proposal as an alternative to the use of the more or less broken certificate trust chain infrastructure.

to post comments

SMTP Strict Transport Security

Posted Apr 21, 2016 8:44 UTC (Thu) by grawity (subscriber, #80596) [Link] (8 responses)

How would it help?

You still need a way of knowing whether the server supports the new security protocol, whether it's STARTTLS or the traditional SMTPS-on-465 (which, by the way, has already been reallocated to a different protocol years ago).

If firewalls can strip the string "STARTTLS" from packet data, it's even easier to block all TCP port 465 connections. A fake TCP RST is nearly indistinguishable from a real one, and once you receive an -ECONNREFUSED, you have to fall back to regular port 25 anyway, because the world isn't going to enable SMTPS in a blink.

As for "the regular TLS certificate trust infrastructure for HTTPS, or DANE, could then be reused…", well, isn't that exactly the same as now?

SMTP Strict Transport Security

Posted Apr 21, 2016 14:49 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> You still need a way of knowing whether the server supports the new security protocol,

Thats where the reference to STS comes in, you add a new capability flag to EHLO that signifies that all further communication with that server should happen over TLS directly, so the first connection caches that information and all subsequent connections can't be downgraded because they aren't relying on checking for a cleartext STARTTLS flag every time. Of course if the first connection you make strips this info, then you can be downgraded, just like with SSH or other protocols that cache security relevant information on first connection, but that's a different kind of risk.

Over time you can switch clients to TLS by default and will see fewer and fewer clients who need the hinting or require the fall back cleartext protocol, giving you a real sense of when you can safely sunset to old protocol.

SMTP Strict Transport Security

Posted Apr 21, 2016 14:53 UTC (Thu) by eduard.munteanu (guest, #66641) [Link]

I don't get it. If anything, a secured connection is client policy. If the server claims not to support it, then you have two scenarios:

1. You're an opportunistic user - you do choose to fall back to unsecured SMTP, but you don't really need a secure connection anyway

2. You mandate a secure connection - you don't fall back and do not use the service

A man in the middle can deny service, but we already knew that.

SMTP Strict Transport Security

Posted Apr 21, 2016 21:40 UTC (Thu) by fredrik (subscriber, #232) [Link] (4 responses)

How it would help? It would help by removing the plain text component entirely from the equation in the long run.

Yes, short term it wouldn't be any better than today, or today plus a slightly modified version of the SMTP-STS proposal. And yes, we'd need to establish a new port number for STMPS. And indeed, in the short term we would probably have to support the STARTTLS upgrade negotiable, but initially plain text, communication channel on port 25 too. As a deprecated fallback.

But, after a while I'm suggesting that many email admins would say: Hey, apart from legacy spam bots, I don't get a whole lot of authentic email over port 25. It all goes to the new port XX25/TLS. You know what, I'm just going to stop accepting email on port 25.

As a poor analogy, your ssh client doesn't bother checking if it can fallback to the telnet or rlogin port if it fails on port 22. It just fails with connection refused. That's my future, no plain text fallback to anything, just encrypt or fail. And no pointless plain text upgrade when all servers have made STARTTLS mandatory anyway.

SMTP Strict Transport Security

Posted Apr 21, 2016 22:11 UTC (Thu) by neilbrown (subscriber, #359) [Link] (3 responses)

> How it would help? It would help by removing the plain text component entirely from the equation in the long run.

I don't think you remove it, just reduce and hide it.

The TCP connection to this new port starts with "SYN" "SYN-ACK" , "ACK", which are all plain "text".
So the client will always have to send some data which is open to snooping and accept some which is open to forging. The only difference between SMTPS and STARTTLS is how the secure components are encapsulated. That isn't a very interesting difference.

SMTP Strict Transport Security

Posted Apr 22, 2016 2:43 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

The distinction isn't between SMTPS and STARTTLS though, it's between enforced SMTPS and a downgrade attack where you never see the STARTTLS signal so silently fall back to plain text.

SMTP Strict Transport Security

Posted Apr 22, 2016 2:59 UTC (Fri) by neilbrown (subscriber, #359) [Link] (1 responses)

The client must have made a deliberate choice to use SMTPS rather than SMTP.
I don't see how that it different to a deliberate choice to abort a connection if STARTTLS isn't offered, or fails.

Both ends of the connection can choose which levels of security are acceptable. A MITM attacker can always force the connection to use the lowest mutually acceptable level. The particular details of the negotiation are only of interest to implementers.

SMTP Strict Transport Security

Posted Apr 22, 2016 16:01 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Doesn't that just break compatibility with existing servers if clients start blindly refusing to communicate with servers unless they have SMTPS/STARTTLS, without caching some minimum expectation of the security features that the server should be providing. You want clients and servers to be able to negotiate and speak any generation of the protocol, without renegotiating every time as that opens you up to trivial protocol downgrades.

A better question is why not just have clients cache the highest level of protocol you've detected for any particular server, and not allow negotiations to any lower version of protocol, my guess is that this has been thought through more clearly by the implementers who found that explicit notification from the server to engage this behavior fixes some corner cases. Many servers who offer STARTTLS today do so with invalid or expired certificates, I'm not even sure it's well defined what should be verified in the certificate to validate a connection today, you would not want clients to reject invalid certificates deployed today, but you would want to reject invalid certificates if the server owner has signaled that they expect them to be valid. Even better is that this policy signalling is out of band, via HTTPS or DNSSEC, that is harder to MITM today.

SMTP Strict Transport Security

Posted Apr 25, 2016 8:35 UTC (Mon) by jond (subscriber, #37669) [Link]

> which, by the way, has already been reallocated to a different protocol years ago

Oh wow. I noticed that it said something different in `/etc/services` recently, but I hadn't put two-and-two together. I never turned off SMTPS. I'm pretty surprised they reallocated that port, it seems a bit premature.