Simple Mail Transfer Protocol (SMTP), that staple of e-mail communications, was born in an era when nobody thought the Internet needed security.
While extensions have been written since to fix this – the most important is STARTTLS – there remains a problem: STARTTLS doesn't yet guarantee either message confidentiality or proof of server authenticity.
A proposal from experts from some big-name companies aims to fix that.
The Internet-Draft document, not yet an RFC, has names from Google, Yahoo!, Comcast, Microsoft, LinkedIn, and German outfit 1&1 Mail and Media Development and Technology (note: IETF authors aren't necessarily endorsed by their employers; they work as individuals).
As they explain: STARTTLS is subject to downgrade attacks, which undermines confidentiality; and because “the trust relationship from email domain to MTA server identity is not cryptographically validated,” users can't guarantee the authenticity of servers handling their e-mails.
Fixing this doesn't need new encryption techniques, but systems need to know each others' capabilities. Hence the draft, SMTP Strict Transport Security, which allows recipient domains to tell senders whether they support TLS, how MTAs should validate TLS server certificates, and what senders should do if TLS negotiation fails.
Importantly, in the context of an Internet that's got a lot of different systems of wildly varying vintage, SMTP STS supports an incremental rollout.
As well as the mechanism for reporting failed crypto negotiations to users,it also features a report-only mode, “enabling progressive roll-out and auditing for compliance”, the document says.
While another proposal, DANE, offers similar capabilities, it depends on DNSSEC, which isn't required by the latest draft.
SMTP STS, on the other hand, uses the certificate authority (CA) system, combined with “a trust-on-first-use (TOFU) approach to avoid interception” (that is, a model that prompts the user to accept credentials the first time a server is encountered).
SMTP STS can, the document notes, be used with DANE, in which case users and sysadmins get the benefits of failure reporting.
The key components of policies are version (naturally enough), the TLS-Only field that stipulates messages can only be delivered to secure message transfer agents (MTAs); MX patterns; authentication mechanisms; recipient MX constraints; policy lifetime; and reply-to address.
Under "future work" the authors list possibilities like certificate pinning, policy distribution mechanisms, receive-from restrictions, and restricting cipher and TLS versions. ®