SMTP Strict Transport Security [LWN.net]

SMTP Strict Transport Security

Posted Apr 21, 2016 21:40 UTC (Thu) by fredrik (subscriber, #232)
In reply to: SMTP Strict Transport Security by grawity
Parent article: SMTP Strict Transport Security

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.

to post comments

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.