SMTP Strict Transport Security

Posted Apr 22, 2016 2:43 UTC (Fri) by raven667 (subscriber, #5198)
In reply to: SMTP Strict Transport Security by neilbrown
Parent article: SMTP Strict Transport Security

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.