NIST SP 800-177 REV. 1 TRUSTWORTHY EMAIL
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1
recipient’s mailbox. TLS [RFC5246] can be used to protect email in transit for one or more hops,
but intervening hops may be under autonomous control, so a securely encrypted end-to-end path
cannot be guaranteed. �is is discussed further in section 5.2.1. Opportunistic encryption over
some portions of the path can provide “better-than-nothing” security. �e use of STARTTLS
[RFC3207] is a standard method for establishing a TLS connection. TLS has a secure handshake
that relies on asymmetric encryption, to establish a secure session (using symmetric encryption).
As part of the handshake, the server sends the client an X.509 certificate containing its public
key, and the cipher suite and symmetric key are negotiated with a preference for the optimally
strongest cipher that both parties support. SMTP clients have traditionally not verified the
server’s certificate due to the lack of an appropriate mechanism to specify allowable certificates
and certificate authorities. �e newly adopted RFC 7672 [RFC 7672] rectifies this, by providing
rules for applying the DANE protocol to SMTP servers. �e use of DANE in conjunction with
SMTP is discussed Section 5.2.4.
Ultimately the entire path from sender to receiver will be protected by TLS. But this may consist
of many hops between MTAs, each the subject of a separate transport connection. �ese are not
compelled to upgrade to TLS at the same time, however in the patchwork evolutionary
development of the global mail system, this cannot be completely guaranteed. �ere may be
some MTAs along the route uncontrolled by the sender or receiver domains that have not
upgraded to TLS. In the interim until all mail nodes are certifiably secure, the principle is that
some incrementally improving security is better than no security, so opportunistic TLS (using
DANE or other methods to validate certificates) should be employed at every possible hop.
5.2.1 TLS Configuration and Use
Traditionally, sending email begins by opening an SMTP connection over TCP and entering a
series of cleartext commands, possibly even including usernames and passwords. �is leaves the
connection exposed to potential monitoring, spoofing, and various man-in-the-middle
interventions. A clear improvement would be to open a secure connection that is encrypted so
that the message contents cannot be passively monitored, and third parties cannot spoof message
headers or contents. Transport Layer Security (TLS) offers the solution to these problems.
TCP provides a reliable, flow-controlled connection for transmitting data between two peers.
Unfortunately, TCP provides no built-in security. Transport connections carry all manner of
sensitive traffic, including web pages with financial and sign-in information, as well as email
messages. �is traffic can only be secured through physical isolation, which is not possible on the
Internet, or by encrypting the traffic.
�e Secure Sockets Layer (SSL) was developed to provide a standard protocol for encrypting
TCP connections. SSL evolved into Transport Layer Security (TLS), the most recent version at
the time of writing being Version 1.3 [RFC8446]. TLS negotiates a secure connection between
initiator and responder (typically client and server) parties. �e negotiation entails the exchange
of the server’s certificate, and possibly the client’s certificate, and agreement on a cipher to use
for encrypting the data. In essence, the protocol uses the public-private key pair: the public key
in the server’s certificate, and the server’s closely held private key, to negotiate a symmetric
algorithm and establish a key known to both parties, and with which both can encrypt, transmit