SMTP Strict Transport Security

It is no secret that email has been a weak point in the security of the standard Internet protocol suite for quite some time. While improvements to HTTP and TLS have resulted in more robust web security, mail transfer has lagged behind. Now, a new draft RFC has been submitted to the Internet Engineering Task Force (IETF) that may make SMTP connections substantially more secure, closing loopholes that have made mail transfer vulnerable to man-in-the-middle and cryptographic-downgrade attacks.

The draft is called SMTP Strict Transport Security (SMTP STS), and it was first posted on March 18. The authors work for a variety of well-known technology companies and ISPs, including Google, Yahoo, Comcast, Microsoft, LinkedIn, and 1&1 Internet. It sets out a standard by which a mail server can publish an STS Policy that defines how mail transfer agents (MTAs) can connect using TLS, how they can validate the server's TLS certificate, and what they should do in the case that a TLS session cannot be correctly established. As the name implies, SMTP STS is similar in design to HTTP Strict Transport Security (HSTS), defined in RFC6797.

SMTP was originally defined in RFC821, long before TLS (or SSL) were invented, and sent all messages in the clear. The STARTTLS extension (RFC3207) added support for TLS transport in 2002. Although reports are that STARTTLS has proven popular with mail providers, it suffers from some severe shortcomings.

First, the TLS session is subject to downgrade attacks. In the SMTP session-establishment handshake, the STARTTLS command is sent from one machine to the other, in the clear. Upon receipt, the remote machine is intended to respond by initiating a TLS handshake before the SMTP session continues. But an attacker sitting in between the two machines can simply intercept and drop the STARTTLS command (or overwrite it with garbage), in which case the SMTP session will continue in plaintext.

The second shortcoming is that, in a STARTTLS handshake, client machines do not attempt to verify that the TLS certificate presented by the server actually belongs to the expected domain. Here again, an attacker in the middle can intercept the genuine certificate and replace it with a fraudulent one, without the client knowing the difference.

SMTP STS defines a way for a mail server to publish a public record that TLS is available and that SMTP clients should thus use it when making connections. This record is the STS Policy, and has seven mandatory fields:

• v - the SMTP STS version. Only a value of STS1 is supported.
• to - a boolean indicating whether the server is "TLS Only." If true, then clients who encounter errors in the TLS setup must not deliver any mail to the server.
• mx - a comma-separated list of domains for which the policy applies.
• a - the authentication mechanism clients should use to verify that the policy is authentic. The supported mechanisms are DNSSEC and an HTTPS URI at which the client can separately request the policy and verify that the two copies are identical.
• c - the validation method clients should use to verify the authenticity of the server's TLS certificate. The supported methods are DANE TLSA (RFC7672) and verifying the PKI trust chain on the certificate back to a root certificate authority (that is, traditional TLS identity checking as specified in RFC6125).
• e - the maximum lifetime of the policy.
• rua - the address to which feedback and errors may be reported by the client.

A server can publish its STS Policy at https://example.com/.well-known/smtp-sts or via DNS as a TXT record under the name _smtp_sts.example.com. The draft document further specifies that any errors reported to a server by clients should contain details about where unexpected results were encountered: an expired certificate, a DNSSEC failure, a certificate that does not match the server's domain, and so forth.

As Lucian Constantin at InfoWorld pointed out, one possible security loophole is that the first time a client connects to a server, it has no cached copy of the server's STS Policy to compare, so a man-in-the-middle attacker could, in theory, intercept the first request and return a forged policy instead. That forged policy would, by necessity, include an a field similarly doctored to direct the client to an attacker-controlled server when authenticating the policy.

The draft's support for DNS-based policy publishing provides the means for some additional robustness against man-in-the-middle attacks over what is offered by TLS identity checking. If a server's STS Policy is published as a TXT record in a DNSSEC-protected zone, clients can verify its authenticity. Furthermore, the c field can be used to specify that a DANE TLSA record for the server's TLS certificate is required for validation. Thus, an attacker would have to compromise the DNSSEC server in addition to intercepting the SMTP handshake.

The draft also notes that clients are not obligated to accept STS Policies the first time they retrieve them from a server. Instead, they are permitted to use the rua reporting mechanism to tell the server's administrators what they saw. That report can be sent "offline" or during a different session, potentially allowing failures and suspicious reports to be routed around a man-in-the-middle attack. Such a reporting feature is not found in HSTS; nevertheless, SMTP STS is still a "trust on first use" system.

The authors of the draft list two other options to be considered for future inclusion in STMP STS as well. They are certificate pinning, in which a policy could specify specific certificates that must appear in the certificate-validation chain, and policy distribution, in which sites' policies could be recorded and publicly tracked.

The draft also speculates that it could be worthwhile for a policy to specify the list of cryptographic ciphers and TLS versions that the server accepts, and perhaps to specify that all mail received from the server's domain should be expected to arrive over TLS. The latter feature would, in theory, allow a mail server to check for an STS Policy for incoming mail domains and, thus, reject mail that is "supposed to" arrive over TLS but does not. The draft notes, however, that such a policy would come with its share or potential man-in-the-middle attacks to be guarded against, and may not offer significant gains.

STARTTLS has, no doubt, improved the security of e-mail transfer, but it is far from complete. SMTP STS hopefully closes some of the more egregious holes.