Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409.
This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 25 must, 38 should, 19 may.
3.1 Implicit TLS for POP
- MUSTClients MUST implement the certificate validation mechanism described in [RFC7817].
- MUSTAfter the server sends an +OK greeting, the server and client MUST enter the AUTHORIZATION state, even if a client certificate was supplied during the TLS handshake.
3.2 Implicit TLS for IMAP
- MAYIf a client certificate was provided during the TLS handshake that the server finds acceptable, the server MAY issue a PREAUTH greeting, in which case both the
3.3 Implicit TLS for SMTP Submission
- SHOULDAs a result, clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period.
3.4 Implicit TLS Connection Closure for POP, IMAP, and SMTP Submission
- SHOULDWhen a client or server wishes to close the connection, it SHOULD initiate the exchange of TLS close alerts before TCP connection termination.
- MAYThe client MAY, after sending a TLS close alert, gracefully close the TCP connection (e.g., call the close() function on the TCP socket or otherwise issue a TCP CLOSE ([RFC793], Section 3.5)) without waiting for a TLS response from the server.
4 Use of TLS by Mail Access Servers and Message Submission Servers
- MUSTo MSPs that support POP, IMAP, and/or Message Submission MUST support TLS access for those protocol servers.
- SHOULDo Servers provided by MSPs other than POP, IMAP, and/or Message Submission SHOULD support TLS access and MUST support TLS access for those servers that support authentication via username and password.
- SHOULDo MSPs that support POP, IMAP, and/or Message Submission SHOULD provide and support instances of those services that use Implicit TLS.
- SHOULDo For compatibility with existing MUAs and existing MUA configurations, MSPs SHOULD also, in the near term, provide instances of these services that support STARTTLS.
- SHOULD NOTHowever, servers SHOULD NOT advertise STARTTLS if the use of the STARTTLS command by a client is likely to fail (for example, if the server has no server certificate configured).
- SHOULDo MSPs SHOULD advertise their Mail Access Servers and Mail Submission Servers, using DNS SRV records according to [RFC6186].
- SHOULD(In addition to making correct configuration easier for MUAs, this provides a way by which MUAs can discover when an MSP begins to offer TLS-based services.) Servers supporting TLS SHOULD be advertised in preference to cleartext servers (if offered).
- SHOULDIn addition, servers using Implicit TLS SHOULD be advertised in preference to servers supporting STARTTLS (if offered).
- SHOULDo MSPs SHOULD deprecate the use of cleartext Mail Access Servers and Mail Submission Servers as soon as practicable.
- SHOULDo MSPs currently supporting such use of cleartext SMTP (on port 25) as a means of Message Submission by their users (whether or not requiring authentication) SHOULD transition their users to using TLS (either Implicit TLS or STARTTLS) as soon as practicable.
- MUSTo Mail Access Servers and Mail Submission Servers MUST support TLS 1.2 or later.
- SHOULDo All Mail Access Servers and Mail Submission Servers SHOULD implement the recommended TLS ciphersuites described in [RFC7525] or a future BCP or Standards Track revision of that document.
- SHOULDo As soon as practicable, MSPs currently supporting Secure Sockets Layer (SSL) 2.x, SSL 3.0, or TLS 1.0 SHOULD transition their users to TLS 1.1 or later and discontinue support for those earlier versions of SSL and TLS.
- SHOULDo Mail Submission Servers accepting mail using TLS SHOULD include in the Received field of the outgoing message the TLS ciphersuite of the session in which the mail was received.
- SHOULDo All Mail Access Servers and Mail Submission Servers implementing TLS SHOULD log TLS cipher information along with any connection or authentication logs that they maintain.
4.1 Deprecation of Services Using Cleartext and TLS Versions
- MAYThe specific means employed for deprecation of cleartext Mail Access Servers and Mail Submission Servers MAY vary from one MSP to the next in light of their user communities' needs and constraints.
- MAYFor example, an MSP MAY implement a gradual transition in which, over time, more and more users are forbidden to authenticate to cleartext instances of these servers, thus encouraging those users to migrate to Implicit TLS.
- MUST NOTAfter a user's ability to authenticate to a server using cleartext is revoked, the server denying such access MUST NOT provide any indication over a cleartext channel of whether the user's authentication credentials were valid.
- MUSTAn attempt to authenticate as such a user using either invalid credentials or valid credentials MUST both result in the same indication of access being denied.
- SHOULDAlso, users previously authenticating with passwords sent as cleartext SHOULD be required to change those passwords when migrating to TLS, if the old passwords were likely to have been compromised.
- MAYTransition of users from SSL or TLS 1.0 to later versions of TLS MAY be accomplished by a means similar to that described above.
- RECOMMENDEDIt is RECOMMENDED that new users be required to use TLS version 1.1 or greater from the start.
4.2 Mail Server Use of Client Certificate Authentication
- MAYMail Submission Servers and Mail Access Servers MAY implement client certificate authentication on the Implicit TLS port.
- MUST NOTSuch servers MUST NOT request a client certificate during the TLS handshake unless the server is configured to accept some client certificates as sufficient for authentication and the server has the ability to determine a mail server authorization identity matching such certificates.
- MUSTIf the server accepts the client's certificate as sufficient for authorization, it MUST enable the Simple Authentication and Security Layer (SASL) EXTERNAL mechanism [RFC4422].
- MAYAn IMAPS server MAY issue a PREAUTH greeting instead of enabling SASL EXTERNAL.
4.3 Recording TLS Ciphersuite in "Received" Header Field
- SHOULDThis clause SHOULD be included whenever a Submission server generates a Received header field for a message received via TLS.
- SHOULDThe value included in this additional clause SHOULD be the registered ciphersuite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) included in the "TLS Cipher Suite Registry".
- MAYIn the event that the implementation does not know the name of the ciphersuite (a situation that should be remedied promptly), a four-digit hexadecimal ciphersuite identifier MAY be used.
- MAYIn addition, the Diffie-Hellman group name associated with the ciphersuite MAY be included (when applicable and known) following the ciphersuite name.
4.4 TLS Server Certificate Requirements
- MUSTMSPs MUST maintain valid server certificates for all servers.
- MAYIf a protocol server provides service for more than one mail domain, it MAY use a separate IP address for each domain and/or a server certificate that advertises multiple domains.
4.5.2 SRV Records
- SHOULDMSPs SHOULD advertise SRV records to aid MUAs in determining the proper configuration of servers, per the instructions in [RFC6186].
- SHOULDMSPs SHOULD advertise servers that support Implicit TLS in preference to servers that support cleartext and/or STARTTLS operation.
4.5.3 DNSSEC
- SHOULDAll DNS records advertised by an MSP as a means of aiding clients in communicating with the MSP's servers SHOULD be signed using DNSSEC if and when the parent DNS zone supports doing so.
4.5.4 TLSA Records
- SHOULDMSPs SHOULD advertise TLSA records to provide an additional trust anchor for public keys used in TLS server certificates.
- MUST NOTHowever, TLSA records MUST NOT be advertised unless they are signed using DNSSEC.
5 Use of TLS by Mail User Agents
- SHOULDo MUAs SHOULD be capable of using DNS SRV records to discover Mail Access Servers and Mail Submission Servers that are advertised by an MSP for an account being configured.
- MAYOther means of discovering server configuration information (e.g., a database maintained by the MUA vendor) MAY also be supported.
- SHOULDo MUAs SHOULD be configurable to require a minimum level of confidentiality for any particular Mail Account and refuse to exchange information via any service associated with that Mail Account if the session does not provide that minimum level of confidentiality.
- MUST NOTo MUAs MUST NOT treat a session as meeting a minimum level of confidentiality if the server's TLS certificate cannot be validated.
- MAYo MUAs MAY impose other minimum confidentiality requirements in the future, e.g., in order to discourage the use of TLS versions or cryptographic algorithms in which weaknesses have been discovered.
- SHOULDo MUAs SHOULD provide a prominent indication of the level of confidentiality associated with an account configuration that is appropriate for the user interface (for example, a "lock" icon or changed background color for a visual interface, or some sort of audible indication for an audio user interface), at appropriate times and/or locations, in order to inform the user of the confidentiality of the communications associated with that account.
- MUST NOTIf, however, an MUA provides such an indication, it MUST NOT indicate confidentiality for any connection that does not at least use TLS 1.1 with certificate verification and also meet the minimum confidentiality requirements associated with that account.
- MUSTo MUAs MUST implement TLS 1.2 [RFC5246] or later.
- MAYEarlier TLS and SSL versions MAY also be supported, so long as the MUA requires at least TLS 1.1 [RFC4346] when accessing accounts that are configured to impose minimum confidentiality requirements.
- SHOULDo All MUAs SHOULD implement the recommended TLS ciphersuites described in [RFC7525] or a future BCP or Standards Track revision of that document.
- SHOULDo MUAs that are configured to not require minimum confidentiality for one or more accounts SHOULD detect when TLS becomes available on those accounts (using [RFC6186] or other means) and offer to upgrade the account to require TLS.
5.1 Use of SRV Records in Establishing Configuration
- SHOULDUser-configurable MUAs SHOULD support the use of [RFC6186] for account setup.
- SHOULDHowever, when using configuration information obtained via this method, MUAs SHOULD ignore advertised services that do not satisfy minimum confidentiality requirements, unless the user has explicitly requested reduced confidentiality.
- SHOULD NOTWhen using configuration information per [RFC6186], MUAs SHOULD NOT automatically establish new configurations that do not require TLS for all servers, unless there are no advertised configurations using TLS.
- SHOULDIf such a configuration is chosen, prior to attempting to authenticate to the server or use the server for Message Submission, the MUA SHOULD warn the user that traffic to that server will not be encrypted and that it will therefore likely be intercepted by unauthorized parties.
- MUST NOTSimilarly, an MUA MUST NOT attempt to "test" a particular Mail Account configuration by submitting the user's authentication credentials to a server, unless a TLS session meeting minimum confidentiality levels has been established with that server.
- SHOULDWhen establishing a new configuration for connecting to an IMAP, POP, or SMTP submission server, based on SRV records, an MUA SHOULD verify that either (a) the SRV records are signed using DNSSEC or (b) the target Fully Qualified Domain Name (FQDN) of the SRV record matches the original server FQDN for which the SRV queries were made.
- SHOULDIf the target FQDN is not in the queried domain, the MUA SHOULD verify with the user that the SRV target FQDN is suitable for use, before executing any connections to the host.
- MUST NOTAn MUA MUST NOT consult SRV records to determine which servers to use on every connection attempt, unless those SRV records are signed by DNSSEC and have a valid signature.
- MAYHowever, an MUA MAY consult SRV records from time to time to determine if an MSP's server configuration has changed and alert the user if it appears that this has happened.
5.2 Minimum Confidentiality Level
- SHOULDMUAs SHOULD, by default, require a minimum level of confidentiality for services accessed by each account.
- SHOULDFor MUAs supporting the ability to access multiple Mail Accounts, this requirement SHOULD be configurable on a per-account basis.
- MUSTThe default minimum expected level of confidentiality for all new accounts MUST require successful validation of the server's certificate and SHOULD require negotiation of TLS version 1.1 or greater.
- MAYMUAs MAY permit the user to disable this minimum confidentiality requirement during initial account configuration or when subsequently editing an account configuration but MUST warn users that such a configuration will not assure privacy for either passwords or messages.
- MUST NOTAn MUA that is configured to require a minimum level of confidentiality for a Mail Account MUST NOT attempt to perform any operation other than capability discovery, or STARTTLS for servers not using Implicit TLS, unless the minimum level of confidentiality is provided by that connection.
- SHOULD NOTMUAs SHOULD NOT allow users to easily access or send mail via a connection, or authenticate to any service using a password, if that account is configured to impose minimum confidentiality requirements and that connection does not meet all of those requirements.
- SHOULDAn MUA that is not configured to require a minimum level of confidentiality for a Mail Account SHOULD still attempt to connect to the services associated with that account using the most secure means available, e.g., by using Implicit TLS or STARTTLS.
5.3 Certificate Validation
- MUSTMUAs MUST validate TLS server certificates according to [RFC7817] and PKIX [RFC5280].
- MAYMUAs MAY also support DNS-Based Authentication of Named Entities (DANE) [RFC6698] as a means of validating server certificates in order to meet minimum confidentiality requirements.
- MAYMUAs MAY support the use of certificate pinning but MUST NOT consider a connection in which the server's authenticity relies on certificate pinning as providing the minimum level of confidentiality.
5.4 Certificate Pinning
- MAYIn the event that the certificate does not validate due to an expired certificate, a lack of an appropriate chain of trust, or a lack of an identifier match, the MUA MAY offer to create a persistent binding between that certificate and the saved hostname for the server, for use when accessing that account's servers.
- MUST NOTCertificate pinning is only appropriate during Mail Account setup and MUST NOT be offered as an option in response to a failed certificate validation for an existing Mail Account.
- MUST NOTAn MUA that allows certificate pinning MUST NOT allow a certificate pinned for one account to validate connections for other accounts.
- MUSTAn MUA that allows certificate pinning MUST also allow a user to undo the pinning, i.e., to revoke trust in a certificate that has previously been pinned.
- MUST NOTTherefore, the use of a pinned certificate does not meet the requirement for a minimum confidentiality level, and an MUA MUST NOT indicate to the user that such confidentiality is provided.
5.5 Client Certificate Authentication
- MAYMUAs MAY implement client certificate authentication on the Implicit TLS port.
- MUST NOTAn MUA MUST NOT provide a client certificate during the TLS handshake unless the server requests one and the MUA has been authorized to use that client certificate with that account.
- MUST NOTHowever, installing a client certificate for use with one account MUST NOT automatically authorize the use of that certificate with other accounts.
- MUSTA client supporting client certificate authentication with Implicit TLS MUST implement the SASL EXTERNAL mechanism [RFC4422], using the appropriate authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP Submission [RFC4954], or AUTHENTICATE for IMAP [RFC3501]).