Motivating SMTP over TLS

With the Snowden revelations that began a little over a year ago, many people started paying a lot more attention to what is being sent in the clear (unencrypted) over the Internet. One of the areas where unencrypted transmission has been common is the passing of email between mail servers using SMTP. Fortunately there is a protocol, commonly referred to as STARTTLS, that supports encrypted transmission between mail servers when both the sending and receiving servers support it. But since many email servers do not support STARTTLS, the vast majority of email continues to be sent in the clear.

To deal with this situation, organizations like EFF have launched campaigns to raise awareness of the need for mail servers to support STARTTLS. Tools, notably starttls.info, have been written and deployed to allow the easy checking of STARTTLS support for incoming mail traffic and in the process to collect statistics on STARTTLS deployment. This is not the first time pushes for STARTTLS deployment have been made; several years ago the Online Trust Alliance (OTA) also advocated for STARTTLS deployment, with very limited success (although this was well before the Snowden revelations).

Getting more awareness and visibility of STARTTLS deployment is of course a good thing. But STARTTLS’s greatest advantages, its transparency and that it doesn’t require users to change or deploy new software, makes it harder to motivate email service providers to deploy it. Few users will be willing to change their email provider based on the provider’s deployment of STARTTLS, and there is little direct benefit for the providers themselves. Shaming service providers into deployment only goes so far.

Some of you will recognize similarities between this deployment problem and that of getting websites to use HTTPS. But in the case of HTTPS, at least there is some visibility in the menu bar that you can look for before sending any sensitive information. But STARTTLS is largely invisible to end users; senders have no way of knowing whether their messages will be encrypted in transit.

Email is also subject to what I call the “nor rain nor snow nor sleet nor hail” bias. Email is designed around the concept of getting the message through, at the expense of other things. For example, if a STARTTLS negotiation finds that the receiving mail server has an invalid certificate, it will send the message anyway, even though it might be sending it to a man-in-the-middle attacker.

A year or so ago, on the then-new IETF PerPass (pervasive passive monitoring) mailing list, I suggested an extension to SMTP and the mail message format that would allow senders to specify that they want a given message sent with STARTTLS, or with STARTTLS only using valid certificates, or not at all. This might be something to use for those messages to one’s attorney or accountant that aren’t sensitive enough to use S/MIME or PGP, but not something that you want easily intercepted either.

Unfortunately, this got a lukewarm response. Some responses expressed an opinion that we only should be looking at end-to-end security, not transport security. Others pointed to issues with traffic analysis, calling attention to encrypted traffic, etc. There wasn’t a whole lot of supportive comment, so I didn’t push the idea, but I still like it. At least it might give domain mail administrators a reason to deploy STARTTLS: they want their users to be able to receive mail marked to only be transmitted over encrypted channels.

This would require a bit of development and significant deployment, so it would take some time to happen, best case. But deliverability shouldn’t always override security. It would also give domains a better motivation to deploy STARTTLS: they might not get all their mail unless they do. That’s a more tangible reason to do the right thing.

Image “Drifts spare the mail” by Flickr user mediageek used under Creative Commons BY-NC-SA 2.0 license.