Requiring TLS transmission of email

It’s considered a “best practice” to support Transport Level Security (TLS), which encrypts traffic over the internet (including this web page), for submission and relay of email messages. Yet many email messages are sent without TLS protection, unbeknownst to their senders, so it’s not something that can be depended upon. Email systems generally prioritize delivery of email over security (something I refer to as the “nor rain nor sleet” principle) so if TLS can’t be negotiated for some reason, the message is sent in the clear.

This past week, the Internet Engineering Task Force (IETF) published “SMTP Require TLS Option” as a Standards Track specification, RFC 8689, to address this.

A few years ago, I became aware of research [1] providing strong evidence that certain countries, notably Tunisia, actively interfere in the negotiation of TLS on email connections, presumably so that they can intercept and read the traffic. It occurred to me that for sensitive traffic it might be preferable to allow the message to be sent only if TLS can be successfully negotiated, and to return an error if this can’t be done. So in early 2016 I wrote the first draft of the REQUIRETLS specification, and submitted it as an IETF Internet Draft.

The way it works is this: when email is sent using the SMTP protocol over the internet, it can be tagged with a “REQUIRETLS” option. Messages tagged with this option can only be sent to mail servers over TLS connections that verify the SMTP server’s identity, and where the mail server receiving the message also advertises that they also support and honor the REQUIRETLS option for onward relay of the message. If none of the email servers to which the message could be relayed meet those requirements, a “bounce” message is returned to the sender.

This raised a number of questions, such as:

• Why not use end-to-end encryption, such as S/MIME or PGP? These encrypt only the body of the message, so all the header information (To and From addresses, Subject, etc.) are still exposed. This is very valuable information for adversaries doing traffic analysis. You often want both transport-level encryption (TLS) and end-to-end content encryption.
• What’s to prevent a mail server from advertising REQUIRETLS and then not honoring it? Nothing, but we’re talking about mail servers that the recipient trusts enough to allow them to be used to accept email on their behalf, so one expects they’re trustworthy enough also to honor a commitment to do REQUIRETLS properly.

As it happened, a complementary specification, MTA-STS, was in the standardization process and intending to solve a similar problem. The goal of MTA-STS is to allow a domain that receives email to advertise the fact that they support TLS, so that if it cannot be negotiated the discrepancy can be detected. One of the challenges with MTA-STS is how to advertise that fact in a way that cannot be altered by an intermediate adversary. This is addressed in the MTA-STS specification, RFC 8461. This is also the goal of DANE, an existing protocol (RFC 7672) that allows domains with DNS Security (DNSSEC) configured to advertise their use of TLS.

But another challenge is how the sender of a sensitive message can know that MTA-STS will be checked as the message is relayed. They might know that the recipient domain publishes an MTA-STS policy, but it’s harder to know whether or not the intermediate hops will honor that policy. It’s in this way that MTA-STS and REQUIRETLS are complementary.

On the way to standardization, one significant additional feature was added. There are times when the sender of a message wants explicitly to ignore MTA-STS and DANE policies, for example when they want to report a misconfiguration in these mechanisms. A new header field, Require-TLS (with mandatory value NO) was added to allow that to be asserted. Servers that support REQUIRETLS and encounter this header field are expected to relay the message without regard to those policy mechanisms. Of course, since the goal is to enhance delivery of the message, it isn’t appropriate to relay the message only if the recipient SMTP server supports it, so support of this header field can’t be depended upon by the sender.

At this writing, no known commercial products yet support REQUIRETLS, although I have been in touch with the MDaemon people who are actively implementing it for their products. There was also an early implementation for the Exim open-source mail server that needs to be brought up to date with the latest specification.

REQUIRETLS is a bit of email infrastructure; nothing in the specification addresses how users will turn it on, either on a per-message or per-domain basis, or for all messages they send. I’m hoping to see some creative solutions for that: perhaps a button on the user interface or some rule causing mail to particular domains or addresses to be tagged REQUIRETLS.

I’m hoping that now that it’s a published standards-track specification, REQUIRETLS becomes a standard part of the email toolkit to enhance senders’ control over the security of messages they send.

[1] Durumeric, Zakir, J. Alex Halderman, David Adrian, Ariana Mirian, James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, and Michael Bailey. 2015. “Neither Snow Nor Rain Nor MITM…: An Empirical Analysis of Email Delivery Security.” In , 27–39. ACM Press. https://doi.org/10.1145/2815675.2815695.