doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc8314.txt b/doc/rfc/rfc8314.txt
new file mode 100644
index 0000000..2abaa77
--- /dev/null
+++ b/doc/rfc/rfc8314.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          K. Moore
+Request for Comments: 8314                                Windrock, Inc.
+Updates: 1939, 2595, 3501, 5068, 6186, 6409                    C. Newman
+Category: Standards Track                                         Oracle
+ISSN: 2070-1721                                             January 2018
+
+
+  Cleartext Considered Obsolete: Use of Transport Layer Security (TLS)
+                    for Email Submission and Access
+
+Abstract
+
+   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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8314.
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Moore & Newman               Standards Track                    [Page 1]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. How This Document Updates Previous RFCs ....................3
+   2. Conventions and Terminology Used in This Document ...............4
+   3. Implicit TLS ....................................................5
+      3.1. Implicit TLS for POP .......................................5
+      3.2. Implicit TLS for IMAP ......................................5
+      3.3. Implicit TLS for SMTP Submission ...........................6
+      3.4. Implicit TLS Connection Closure for POP, IMAP, and
+           SMTP Submission ............................................7
+   4. Use of TLS by Mail Access Servers and Message Submission
+      Servers .........................................................7
+      4.1. Deprecation of Services Using Cleartext and TLS Versions
+           Less Than 1.1 ..............................................8
+      4.2. Mail Server Use of Client Certificate Authentication .......9
+      4.3. Recording TLS Ciphersuite in "Received" Header Field .......9
+      4.4. TLS Server Certificate Requirements .......................10
+      4.5. Recommended DNS Records for Mail Protocol Servers .........11
+           4.5.1. MX Records .........................................11
+           4.5.2. SRV Records ........................................11
+           4.5.3. DNSSEC .............................................11
+           4.5.4. TLSA Records .......................................11
+      4.6. Changes to Internet-Facing Servers ........................11
+   5. Use of TLS by Mail User Agents .................................12
+      5.1. Use of SRV Records in Establishing Configuration ..........13
+      5.2. Minimum Confidentiality Level .............................14
+      5.3. Certificate Validation ....................................15
+      5.4. Certificate Pinning .......................................15
+      5.5. Client Certificate Authentication .........................16
+   6. Considerations Related to Antivirus/Antispam Software
+      and Services ...................................................17
+   7. IANA Considerations ............................................17
+      7.1. POP3S Port Registration Update ............................17
+      7.2. IMAPS Port Registration Update ............................18
+      7.3. Submissions Port Registration .............................18
+      7.4. Additional Registered Clauses for "Received" Fields .......19
+   8. Security Considerations ........................................19
+   9. References .....................................................20
+      9.1. Normative References ......................................20
+      9.2. Informative References ....................................22
+   Appendix A. Design Considerations .................................24
+   Acknowledgements ..................................................26
+   Authors' Addresses ................................................26
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                    [Page 2]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+1.  Introduction
+
+   Software that provides email service via the Internet Message Access
+   Protocol (IMAP) [RFC3501], the Post Office Protocol (POP) [RFC1939],
+   and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409]
+   usually has Transport Layer Security (TLS) [RFC5246] support but
+   often does not use it in a way that maximizes end-user
+   confidentiality.  This specification describes current
+   recommendations for the use of TLS in interactions between Mail User
+   Agents (MUAs) and Mail Access Servers, and also between MUAs and Mail
+   Submission Servers.
+
+   In brief, this memo now recommends that:
+
+   o  TLS version 1.2 or greater be used for all traffic between MUAs
+      and Mail Submission Servers, and also between MUAs and Mail Access
+      Servers.
+
+   o  MUAs and Mail Service Providers (MSPs) (a) discourage the use of
+      cleartext protocols for mail access and mail submission and
+      (b) deprecate the use of cleartext protocols for these purposes as
+      soon as practicable.
+
+   o  Connections to Mail Submission Servers and Mail Access Servers be
+      made using "Implicit TLS" (as defined below), in preference to
+      connecting to the "cleartext" port and negotiating TLS using the
+      STARTTLS command or a similar command.
+
+   This memo does not address the use of TLS with SMTP for message relay
+   (where Message Submission [RFC6409] does not apply).  Improving the
+   use of TLS with SMTP for message relay requires a different approach.
+   One approach to address that topic is described in [RFC7672]; another
+   is provided in [MTA-STS].
+
+   The recommendations in this memo do not replace the functionality of,
+   and are not intended as a substitute for, end-to-end encryption of
+   electronic mail.
+
+1.1.  How This Document Updates Previous RFCs
+
+   This document updates POP (RFC 1939), IMAP (RFC 3501), and Submission
+   (RFC 6409, RFC 5068) in two ways:
+
+   1.  By adding Implicit TLS ports as Standards Track ports for these
+       protocols as described in Section 3.
+
+   2.  By updating TLS best practices that apply to these protocols as
+       described in Sections 4 and 5.
+
+
+
+Moore & Newman               Standards Track                    [Page 3]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   This document updates RFC 2595 by replacing Section 7 of RFC 2595
+   with the preference for Implicit TLS as described in Sections 1 and 3
+   of this document, as well as by updating TLS best practices that
+   apply to the protocols in RFC 2595 as described in Sections 4 and 5
+   of this document.
+
+   This document updates RFC 6186 as described herein, in Section 5.1.
+
+2.  Conventions and Terminology Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   The term "Implicit TLS" refers to the automatic negotiation of TLS
+   whenever a TCP connection is made on a particular TCP port that is
+   used exclusively by that server for TLS connections.  The term
+   "Implicit TLS" is intended to contrast with the use of STARTTLS and
+   similar commands in POP, IMAP, SMTP Message Submission, and other
+   protocols, that are used by the client and the server to explicitly
+   negotiate TLS on an established cleartext TCP connection.
+
+   The term "Mail Access Server" refers to a server for POP, IMAP, and
+   any other protocol used to access or modify received messages, or to
+   access or modify a mail user's account configuration.
+
+   The term "Mail Submission Server" refers to a server for the protocol
+   specified in [RFC6409] (or one of its predecessors or successors) for
+   submission of outgoing messages for delivery to recipients.
+
+   The term "Mail Service Provider" (or "MSP") refers to an operator of
+   Mail Access Servers and/or Mail Submission Servers.
+
+   The term "Mail Account" refers to a user's identity with an MSP, that
+   user's authentication credentials, any user email that is stored by
+   the MSP, and any other per-user configuration information maintained
+   by the MSP (for example, instructions for filtering spam).  Most MUAs
+   support the ability to access multiple Mail Accounts.
+
+   For each account that an MUA accesses on its user's behalf, it must
+   have the server names, ports, authentication credentials, and other
+   configuration information specified by the user.  This information,
+   which is used by the MUA, is referred to as "Mail Account
+   Configuration".
+
+
+
+
+
+Moore & Newman               Standards Track                    [Page 4]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   This specification expresses syntax using the Augmented Backus-Naur
+   Form (ABNF) as described in [RFC5234], including the core rules
+   provided in Appendix B of [RFC5234] and the rules provided in
+   [RFC5322].
+
+3.  Implicit TLS
+
+   Previous standards for the use of email protocols with TLS used the
+   STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501].  With
+   STARTTLS, the client establishes a cleartext application session and
+   determines whether to issue a STARTTLS command based on server
+   capabilities and client configuration.  If the client issues a
+   STARTTLS command, a TLS handshake follows that can upgrade the
+   connection.  Although this mechanism has been deployed, an alternate
+   mechanism where TLS is negotiated immediately at connection start on
+   a separate port (referred to in this document as "Implicit TLS") has
+   been deployed more successfully.  To encourage more widespread use of
+   TLS and to also encourage greater consistency regarding how TLS is
+   used, this specification now recommends the use of Implicit TLS for
+   POP, IMAP, SMTP Submission, and all other protocols used between an
+   MUA and an MSP.
+
+3.1.  Implicit TLS for POP
+
+   When a TCP connection is established for the "pop3s" service (default
+   port 995), a TLS handshake begins immediately.  Clients MUST
+   implement the certificate validation mechanism described in
+   [RFC7817].  Once the TLS session is established, POP3 [RFC1939]
+   protocol messages are exchanged as TLS application data for the
+   remainder of the TCP connection.  After 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.
+
+   See Sections 5.5 and 4.2 for additional information on client
+   certificate authentication.  See Section 7.1 for port registration
+   information.
+
+3.2.  Implicit TLS for IMAP
+
+   When a TCP connection is established for the "imaps" service (default
+   port 993), a TLS handshake begins immediately.  Clients MUST
+   implement the certificate validation mechanism described in
+   [RFC7817].  Once the TLS session is established, IMAP [RFC3501]
+   protocol messages are exchanged as TLS application data for the
+   remainder of the TCP connection.  If 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
+
+
+
+
+Moore & Newman               Standards Track                    [Page 5]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   server and the client enter the AUTHENTICATED state.  If the server
+   issues an OK greeting, then both the server and the client enter the
+   NOT AUTHENTICATED state.
+
+   See Sections 5.5 and 4.2 for additional information on client
+   certificate authentication.  See Section 7.2 for port registration
+   information.
+
+3.3.  Implicit TLS for SMTP Submission
+
+   When a TCP connection is established for the "submissions" service
+   (default port 465), a TLS handshake begins immediately.  Clients MUST
+   implement the certificate validation mechanism described in
+   [RFC7817].  Once the TLS session is established, Message Submission
+   protocol data [RFC6409] is exchanged as TLS application data for the
+   remainder of the TCP connection.  (Note: The "submissions" service
+   name is defined in Section 7.3 of this document and follows the usual
+   convention that the name of a service layered on top of Implicit TLS
+   consists of the name of the service as used without TLS, with an "s"
+   appended.)
+
+   The STARTTLS mechanism on port 587 is relatively widely deployed due
+   to the situation with port 465 (discussed in Section 7.3).  This
+   differs from IMAP and POP services where Implicit TLS is more widely
+   deployed on servers than STARTTLS.  It is desirable to migrate core
+   protocols used by MUA software to Implicit TLS over time, for
+   consistency as well as for the additional reasons discussed in
+   Appendix A.  However, to maximize the use of encryption for
+   submission, it is desirable to support both mechanisms for Message
+   Submission over TLS for a transition period of several years.  As a
+   result, clients and servers SHOULD implement both STARTTLS on
+   port 587 and Implicit TLS on port 465 for this transition period.
+   Note that there is no significant difference between the security
+   properties of STARTTLS on port 587 and Implicit TLS on port 465 if
+   the implementations are correct and if both the client and the server
+   are configured to require successful negotiation of TLS prior to
+   Message Submission.
+
+   Note that the "submissions" port provides access to a Message
+   Submission Agent (MSA) as defined in [RFC6409], so requirements and
+   recommendations for MSAs in that document, including the requirement
+   to implement SMTP AUTH [RFC4954] and the requirements of Email
+   Submission Operations [RFC5068], also apply to the submissions port.
+
+   See Sections 5.5 and 4.2 for additional information on client
+   certificate authentication.  See Section 7.3 for port registration
+   information.
+
+
+
+
+Moore & Newman               Standards Track                    [Page 6]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+3.4.  Implicit TLS Connection Closure for POP, IMAP, and SMTP Submission
+
+   When a client or server wishes to close the connection, it SHOULD
+   initiate the exchange of TLS close alerts before TCP connection
+   termination.  The 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
+
+   The following requirements and recommendations apply to Mail Access
+   Servers and Mail Submission Servers, or, if indicated, to MSPs:
+
+   o  MSPs that support POP, IMAP, and/or Message Submission MUST
+      support TLS access for those protocol servers.
+
+   o  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.
+
+   o  MSPs that support POP, IMAP, and/or Message Submission SHOULD
+      provide and support instances of those services that use Implicit
+      TLS.  (See Section 3.)
+
+   o  For compatibility with existing MUAs and existing MUA
+      configurations, MSPs SHOULD also, in the near term, provide
+      instances of these services that support STARTTLS.  This will
+      permit legacy MUAs to discover new availability of TLS capability
+      on servers and may increase the use of TLS by such MUAs.  However,
+      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).
+
+   o  MSPs SHOULD advertise their Mail Access Servers and Mail
+      Submission Servers, using DNS SRV records according to [RFC6186].
+      (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).  In
+      addition, servers using Implicit TLS SHOULD be advertised in
+      preference to servers supporting STARTTLS (if offered).  (See also
+      Section 4.5.)
+
+   o  MSPs SHOULD deprecate the use of cleartext Mail Access Servers and
+      Mail Submission Servers as soon as practicable.  (See
+      Section 4.1.)
+
+
+
+Moore & Newman               Standards Track                    [Page 7]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   o  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.
+
+   o  Mail Access Servers and Mail Submission Servers MUST support
+      TLS 1.2 or later.
+
+   o  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.
+
+   o  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.
+
+   o  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.  (See Section 4.3.)
+
+   o  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.
+
+   Additional considerations and details appear below.
+
+4.1.  Deprecation of Services Using Cleartext and TLS Versions
+      Less Than 1.1
+
+   The 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.  For
+   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.  Access to cleartext servers should eventually be
+   either (a) disabled or (b) limited strictly for use by legacy systems
+   that cannot be upgraded.
+
+   After 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.  An 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.
+
+
+
+
+
+Moore & Newman               Standards Track                    [Page 8]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   Also, 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.
+   (For any large community of users using the public Internet to access
+   mail without encryption, the compromise of at least some of those
+   passwords should be assumed.)
+
+   Transition of users from SSL or TLS 1.0 to later versions of TLS MAY
+   be accomplished by a means similar to that described above.  There
+   are multiple ways to accomplish this.  One way is for the server to
+   refuse a ClientHello message from any client sending a
+   ClientHello.version field corresponding to any version of SSL or
+   TLS 1.0.  Another way is for the server to accept ClientHello
+   messages from some client versions that it does not wish to support
+   but later refuse to allow the user to authenticate.  The latter
+   method may provide a better indication to the user of the reason for
+   the failure but (depending on the protocol and method of
+   authentication used) may also risk exposure of the user's password
+   over a channel that is known to not provide adequate confidentiality.
+
+   It is RECOMMENDED that new users be required to use TLS version 1.1
+   or greater from the start.  However, an MSP may find it necessary to
+   make exceptions to accommodate some legacy systems that support only
+   earlier versions of TLS or only cleartext.
+
+4.2.  Mail Server Use of Client Certificate Authentication
+
+   Mail Submission Servers and Mail Access Servers MAY implement client
+   certificate authentication on the Implicit TLS port.  Such 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.  How to make this determination is presently
+   implementation specific.
+
+   If the server accepts the client's certificate as sufficient for
+   authorization, it MUST enable the Simple Authentication and Security
+   Layer (SASL) EXTERNAL mechanism [RFC4422].  An IMAPS server MAY issue
+   a PREAUTH greeting instead of enabling SASL EXTERNAL.
+
+4.3.  Recording TLS Ciphersuite in "Received" Header Field
+
+   The ESMTPS transmission type [RFC3848] provides trace information
+   that can indicate that TLS was used when transferring mail.  However,
+   TLS usage by itself is not a guarantee of confidentiality or
+   security.  The TLS ciphersuite provides additional information about
+   the level of security made available for a connection.  This section
+
+
+
+Moore & Newman               Standards Track                    [Page 9]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   defines a new SMTP "tls" Received header additional-registered-clause
+   that is used to record the TLS ciphersuite that was negotiated for
+   the connection.  This clause SHOULD be included whenever a Submission
+   server generates a Received header field for a message received via
+   TLS.  The 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".  In 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.  In addition, the Diffie-Hellman group name associated with the
+   ciphersuite MAY be included (when applicable and known) following the
+   ciphersuite name.  The ABNF for the field follows:
+
+   tls-cipher-clause  =  CFWS "tls" FWS tls-cipher
+                         [ CFWS tls-dh-group-clause ]
+
+   tls-cipher         =  tls-cipher-name / tls-cipher-hex
+
+   tls-cipher-name    =  ALPHA *(ALPHA / DIGIT / "_")
+   ; as registered in the IANA "TLS Cipher Suite Registry"
+   ; <https://www.iana.org/assignments/tls-parameters>
+
+   tls-cipher-hex     =  "0x" 4HEXDIG
+
+   tls-dh-group-clause = "group" FWS dh-group
+   ; not to be used except immediately after tls-cipher
+
+   dh-group           = ALPHA *(ALPHA / DIGIT / "_" / "-")
+   ; as registered in the IANA "TLS Supported Groups Registry"
+   ; <https://www.iana.org/assignments/tls-parameters>
+
+4.4.  TLS Server Certificate Requirements
+
+   MSPs MUST maintain valid server certificates for all servers.  See
+   [RFC7817] for the recommendations and requirements necessary to
+   achieve this.
+
+   If 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.  This will generally be
+   necessary unless and until it is acceptable to impose the constraint
+   that the server and all clients support the Server Name Indication
+   (SNI) extension to TLS [RFC6066].  Mail servers supporting the SNI
+   need to support the post-SRV hostname to interoperate with MUAs that
+   have not implemented [RFC6186].  For more discussion of this problem,
+   see Section 5.1 of [RFC7817].
+
+
+
+
+Moore & Newman               Standards Track                   [Page 10]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+4.5.  Recommended DNS Records for Mail Protocol Servers
+
+   This section discusses not only the DNS records that are recommended
+   but also implications of DNS records for server configuration and TLS
+   server certificates.
+
+4.5.1.  MX Records
+
+   It is recommended that MSPs advertise MX records for the handling of
+   inbound mail (instead of relying entirely on A or AAAA records) and
+   that those MX records be signed using DNSSEC [RFC4033].  This is
+   mentioned here only for completeness, as the handling of inbound mail
+   is out of scope for this document.
+
+4.5.2.  SRV Records
+
+   MSPs SHOULD advertise SRV records to aid MUAs in determining the
+   proper configuration of servers, per the instructions in [RFC6186].
+
+   MSPs SHOULD advertise servers that support Implicit TLS in preference
+   to servers that support cleartext and/or STARTTLS operation.
+
+4.5.3.  DNSSEC
+
+   All 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
+
+   MSPs SHOULD advertise TLSA records to provide an additional trust
+   anchor for public keys used in TLS server certificates.  However,
+   TLSA records MUST NOT be advertised unless they are signed using
+   DNSSEC.
+
+4.6.  Changes to Internet-Facing Servers
+
+   When an MSP changes the Internet-facing Mail Access Servers and Mail
+   Submission Servers, including SMTP-based spam/virus filters, it is
+   generally necessary to support the same and/or a newer version of TLS
+   than the one previously used.
+
+
+
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 11]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+5.  Use of TLS by Mail User Agents
+
+   The following requirements and recommendations apply to MUAs:
+
+   o  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.  Other means of
+      discovering server configuration information (e.g., a database
+      maintained by the MUA vendor) MAY also be supported.  (See
+      Section 5.1 for more information.)
+
+   o  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.  (See Section 5.2.)
+
+   o  MUAs MUST NOT treat a session as meeting a minimum level of
+      confidentiality if the server's TLS certificate cannot be
+      validated.  (See Section 5.3.)
+
+   o  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.
+
+   o  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.  For example, this might be done whenever (a) the user is
+      prompted for authentication credentials, (b) the user is composing
+      mail that will be sent to a particular submission server, (c) a
+      list of accounts is displayed (particularly if the user can select
+      from that list to read mail), or (d) the user is asking to view or
+      update any configuration data that will be stored on a remote
+      server.  If, 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.
+
+   o  MUAs MUST implement TLS 1.2 [RFC5246] or later.  Earlier 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.
+
+
+
+Moore & Newman               Standards Track                   [Page 12]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   o  All MUAs SHOULD implement the recommended TLS ciphersuites
+      described in [RFC7525] or a future BCP or Standards Track revision
+      of that document.
+
+   o  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.
+
+   Additional considerations and details appear below.
+
+5.1.  Use of SRV Records in Establishing Configuration
+
+   This document updates [RFC6186] by changing the preference rules and
+   adding a new SRV service label _submissions._tcp to refer to Message
+   Submission with Implicit TLS.
+
+   User-configurable MUAs SHOULD support the use of [RFC6186] for
+   account setup.  However, 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.  This will have the
+   effect of causing the MUA to default to ignoring advertised
+   configurations that do not support TLS, even when those advertised
+   configurations have a higher priority than other advertised
+   configurations.
+
+   When 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.  If 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.  The specific wording is to be determined by
+   the implementation, but it should adequately capture the sense of
+   risk, given the widespread incidence of mass surveillance of email
+   traffic.
+
+   Similarly, 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.  If
+   minimum confidentiality requirements have not been satisfied, the MUA
+   must explicitly warn that the user's password may be exposed to
+   attackers before testing the new configuration.
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 13]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   When 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.  If 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.  (See Section 6 of [RFC6186].)
+
+   An 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.  However, 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.  This can also serve as a means to encourage users to
+   upgrade their configurations to require TLS if and when their MSPs
+   support it.
+
+5.2.  Minimum Confidentiality Level
+
+   MUAs SHOULD, by default, require a minimum level of confidentiality
+   for services accessed by each account.  For MUAs supporting the
+   ability to access multiple Mail Accounts, this requirement SHOULD be
+   configurable on a per-account basis.
+
+   The 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.  (Future revisions to this specification may raise these
+   requirements or impose additional requirements to address newly
+   discovered weaknesses in protocols or cryptographic algorithms.)
+
+   MUAs 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.
+
+   An 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.
+
+   MUAs 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.  An
+
+
+
+Moore & Newman               Standards Track                   [Page 14]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   example of "easy access" would be to display a dialog informing the
+   user that the security requirements of the account were not met by
+   the connection but allowing the user to "click through" to send mail
+   or access the service anyway.  Experience indicates that users
+   presented with such an option often "click through" without
+   understanding the risks that they're accepting by doing so.
+   Furthermore, users who frequently find the need to "click through" to
+   use an insecure connection may become conditioned to do so as a
+   matter of habit, before considering whether the risks are reasonable
+   in each specific instance.
+
+   An 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
+
+   MUAs MUST validate TLS server certificates according to [RFC7817] and
+   PKIX [RFC5280].
+
+   MUAs 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.
+
+   MUAs 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.  (See
+   Section 5.4.)
+
+5.4.  Certificate Pinning
+
+   During account setup, the MUA will identify servers that provide
+   account services such as mail access and mail submission (Section 5.1
+   describes one way to do this).  The certificates for these servers
+   are verified using the rules described in [RFC7817] and PKIX
+   [RFC5280].  In 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.  This
+   is called "certificate pinning".
+
+   (Note: This use of the term "certificate pinning" means something
+   subtly different than HTTP Public Key Pinning as described in
+   [RFC7469].  The dual use of the same term is confusing, but
+   unfortunately both uses are well established.)
+
+
+
+
+Moore & Newman               Standards Track                   [Page 15]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   Certificate 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.  An MUA that allows
+   certificate pinning MUST NOT allow a certificate pinned for one
+   account to validate connections for other accounts.  An 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.
+
+   A pinned certificate is subject to a man-in-the-middle attack at
+   account setup time and typically lacks a mechanism to automatically
+   revoke or securely refresh the certificate.  Note also that a man-in-
+   the-middle attack at account setup time will expose the user's
+   password to the attacker (if a password is used).  Therefore, 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.  Additional advice on certificate
+   pinning is presented in [RFC6125].
+
+5.5.  Client Certificate Authentication
+
+   MUAs MAY implement client certificate authentication on the Implicit
+   TLS port.  An 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.  Having
+   the end user explicitly configure a client certificate for use with a
+   given account is sufficient to meet this requirement.  However,
+   installing a client certificate for use with one account MUST NOT
+   automatically authorize the use of that certificate with other
+   accounts.  This is not intended to prohibit site-specific
+   authorization mechanisms, such as (a) a site-administrator-controlled
+   mechanism to authorize the use of a client certificate with a given
+   account or (b) a domain-name-matching mechanism.
+
+   Note: The requirement that the server request a certificate is just a
+   restatement of the TLS protocol rules, e.g., Section 7.4.6 of
+   [RFC5246].  The requirement that the client not send a certificate
+   not known to be acceptable to the server is pragmatic in multiple
+   ways: the current TLS protocol provides no way for the client to know
+   which of the potentially multiple certificates it should use; also,
+   when the client sends a certificate, it is potentially disclosing its
+   identity (or its user's identity) to both the server and any party
+   with access to the transmission medium, perhaps unnecessarily and for
+   no useful purpose.
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 16]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   A 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]).
+
+6.  Considerations Related to Antivirus/Antispam Software and Services
+
+   There are multiple ways to connect an AVAS service (e.g., "Antivirus
+   & Antispam") to a mail server.  Some mechanisms, such as the de facto
+   "milter" protocol, are out of scope for this specification.  However,
+   some services use an SMTP relay proxy that intercepts mail at the
+   application layer to perform a scan and proxy or forward to another
+   Mail Transfer Agent (MTA).  Deploying AVAS services in this way can
+   cause many problems [RFC2979], including direct interference with
+   this specification, and other forms of confidentiality or security
+   reduction.  An AVAS product or service is considered compatible with
+   this specification if all IMAP, POP, and SMTP-related software
+   (including proxies) it includes are compliant with this
+   specification.
+
+   Note that end-to-end email encryption prevents AVAS software and
+   services from using email content as part of a spam or virus
+   assessment.  Furthermore, although a minimum confidentiality level
+   can prevent a man-in-the-middle from introducing spam or virus
+   content between the MUA and Submission server, it does not prevent
+   other forms of client or account compromise.  The use of AVAS
+   services for submitted email therefore remains necessary.
+
+7.  IANA Considerations
+
+7.1.  POP3S Port Registration Update
+
+   IANA has updated the registration of the TCP well-known port 995
+   using the following template [RFC6335]:
+
+     Service Name: pop3s
+     Transport Protocol: TCP
+     Assignee: IESG <iesg@ietf.org>
+     Contact: IETF Chair <chair@ietf.org>
+     Description: POP3 over TLS protocol
+     Reference: RFC 8314
+     Port Number: 995
+
+
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 17]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+7.2.  IMAPS Port Registration Update
+
+   IANA has updated the registration of the TCP well-known port 993
+   using the following template [RFC6335]:
+
+     Service Name: imaps
+     Transport Protocol: TCP
+     Assignee: IESG <iesg@ietf.org>
+     Contact: IETF Chair <chair@ietf.org>
+     Description: IMAP over TLS protocol
+     Reference: RFC 8314
+     Port Number: 993
+
+   No changes to existing UDP port assignments for pop3s or imaps are
+   being requested.
+
+7.3.  Submissions Port Registration
+
+   IANA has assigned an alternate usage of TCP port 465 in addition to
+   the current assignment using the following template [RFC6335]:
+
+     Service Name: submissions
+     Transport Protocol: TCP
+     Assignee: IESG <iesg@ietf.org>
+     Contact: IETF Chair <chair@ietf.org>
+     Description: Message Submission over TLS protocol
+     Reference: RFC 8314
+     Port Number: 465
+
+   This is a one-time procedural exception to the rules in [RFC6335].
+   This requires explicit IESG approval and does not set a precedent.
+   Note: Since the purpose of this alternate usage assignment is to
+   align with widespread existing practice and there is no known usage
+   of UDP port 465 for Message Submission over TLS, IANA has not
+   assigned an alternate usage of UDP port 465.
+
+   Historically, port 465 was briefly registered as the "smtps" port.
+   This registration made no sense, as the SMTP transport MX
+   infrastructure has no way to specify a port, so port 25 is always
+   used.  As a result, the registration was revoked and was subsequently
+   reassigned to a different service.  In hindsight, the "smtps"
+   registration should have been renamed or reserved rather than
+   revoked.  Unfortunately, some widely deployed mail software
+   interpreted "smtps" as "submissions" [RFC6409] and used that port for
+   email submission by default when an end user requested security
+   during account setup.  If a new port is assigned for the submissions
+   service, either (a) email software will continue with unregistered
+   use of port 465 (leaving the port registry inaccurate relative to
+
+
+
+Moore & Newman               Standards Track                   [Page 18]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   de facto practice and wasting a well-known port) or (b) confusion
+   between the de facto and registered ports will cause harmful
+   interoperability problems that will deter the use of TLS for Message
+   Submission.  The authors of this document believe that both of these
+   outcomes are less desirable than a "wart" in the registry documenting
+   real-world usage of a port for two purposes.  Although STARTTLS on
+   port 587 has been deployed, it has not replaced the deployed use of
+   Implicit TLS submission on port 465.
+
+7.4.  Additional Registered Clauses for "Received" Fields
+
+   Per the provisions in [RFC5321], IANA has added two additional-
+   registered-clauses for Received fields as defined in Section 4.3 of
+   this document:
+
+   o  "tls": Indicates the TLS cipher used (if applicable)
+
+   o  "group": Indicates the Diffie-Hellman group used with the TLS
+      cipher (if applicable)
+
+   The descriptions and syntax of these additional clauses are provided
+   in Section 4.3 of this document.
+
+8.  Security Considerations
+
+   This entire document is about security considerations.  In general,
+   this is targeted to improve mail confidentiality and to mitigate
+   threats external to the email system such as network-level snooping
+   or interception; this is not intended to mitigate active attackers
+   who have compromised service provider systems.
+
+   Implementers should be aware that the use of client certificates with
+   TLS 1.2 reveals the user's identity to any party with the ability to
+   read packets from the transmission medium and therefore may
+   compromise the user's privacy.  There seems to be no easy fix with
+   TLS 1.2 or earlier versions, other than to avoid presenting client
+   certificates except when there is explicit authorization to do so.
+   TLS 1.3 [TLS-1.3] appears to reduce this privacy risk somewhat.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 19]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <https://www.rfc-editor.org/info/rfc793>.
+
+   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
+              STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
+              <https://www.rfc-editor.org/info/rfc1939>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
+              February 2002, <https://www.rfc-editor.org/info/rfc3207>.
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+              VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501,
+              March 2003, <https://www.rfc-editor.org/info/rfc3501>.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <https://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC5034]  Siemborski, R. and A. Menon-Sen, "The Post Office Protocol
+              (POP3) Simple Authentication and Security Layer (SASL)
+              Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034,
+              July 2007, <https://www.rfc-editor.org/info/rfc5034>.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 20]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              DOI 10.17487/RFC5322, October 2008,
+              <https://www.rfc-editor.org/info/rfc5322>.
+
+   [RFC6186]  Daboo, C., "Use of SRV Records for Locating Email
+              Submission/Access Services", RFC 6186,
+              DOI 10.17487/RFC6186, March 2011,
+              <https://www.rfc-editor.org/info/rfc6186>.
+
+   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
+              STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
+              <https://www.rfc-editor.org/info/rfc6409>.
+
+   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+              of Named Entities (DANE) Transport Layer Security (TLS)
+              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
+              August 2012, <https://www.rfc-editor.org/info/rfc6698>.
+
+   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
+              May 2015, <https://www.rfc-editor.org/info/rfc7525>.
+
+   [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via
+              Opportunistic DNS-Based Authentication of Named Entities
+              (DANE) Transport Layer Security (TLS)", RFC 7672,
+              DOI 10.17487/RFC7672, October 2015,
+              <https://www.rfc-editor.org/info/rfc7672>.
+
+   [RFC7817]  Melnikov, A., "Updated Transport Layer Security (TLS)
+              Server Identity Check Procedure for Email-Related
+              Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
+              <https://www.rfc-editor.org/info/rfc7817>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+              RFC 2119 Key Words", BCP 14, RFC 8174,
+              DOI 10.17487/RFC8174, May 2017,
+              <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 21]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+9.2.  Informative References
+
+   [CERT-555316]
+              CERT, "Vulnerability Note VU#555316: STARTTLS plaintext
+              command injection vulnerability", Carnegie Mellon
+              University Software Engineering Institute, September 2011,
+              <https://www.kb.cert.org/vuls/id/555316>.
+
+   [Email-TLS]
+              Moore, K., "Recommendations for use of TLS by Electronic
+              Mail Access Protocols", Work in Progress, draft-moore-
+              email-tls-00, October 2013.
+
+   [MTA-STS]  Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
+              and J. Jones, "SMTP MTA Strict Transport Security
+              (MTA-STS)", Work in Progress, draft-ietf-uta-mta-sts-14,
+              January 2018.
+
+   [POP3-over-TLS]
+              Melnikov, A., Newman, C., and M. Yevstifeyev, Ed., "POP3
+              over TLS", Work in Progress, draft-melnikov-pop3-
+              over-tls-02, August 2011.
+
+   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
+              RFC 2595, DOI 10.17487/RFC2595, June 1999,
+              <https://www.rfc-editor.org/info/rfc2595>.
+
+   [RFC2979]  Freed, N., "Behavior of and Requirements for Internet
+              Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
+              <https://www.rfc-editor.org/info/rfc2979>.
+
+   [RFC3848]  Newman, C., "ESMTP and LMTP Transmission Types
+              Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004,
+              <https://www.rfc-editor.org/info/rfc3848>.
+
+   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346,
+              DOI 10.17487/RFC4346, April 2006,
+              <https://www.rfc-editor.org/info/rfc4346>.
+
+   [RFC4422]  Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422,
+              DOI 10.17487/RFC4422, June 2006,
+              <https://www.rfc-editor.org/info/rfc4422>.
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 22]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   [RFC4954]  Siemborski, R., Ed., and A. Melnikov, Ed., "SMTP Service
+              Extension for Authentication", RFC 4954,
+              DOI 10.17487/RFC4954, July 2007,
+              <https://www.rfc-editor.org/info/rfc4954>.
+
+   [RFC5068]  Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
+              Finch, "Email Submission Operations: Access and
+              Accountability Requirements", BCP 134, RFC 5068,
+              DOI 10.17487/RFC5068, November 2007,
+              <https://www.rfc-editor.org/info/rfc5068>.
+
+   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              DOI 10.17487/RFC5321, October 2008,
+              <https://www.rfc-editor.org/info/rfc5321>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <https://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
+              March 2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+              Cheshire, "Internet Assigned Numbers Authority (IANA)
+              Procedures for the Management of the Service Name and
+              Transport Protocol Port Number Registry", BCP 165,
+              RFC 6335, DOI 10.17487/RFC6335, August 2011,
+              <https://www.rfc-editor.org/info/rfc6335>.
+
+   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
+              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
+              April 2015, <https://www.rfc-editor.org/info/rfc7469>.
+
+   [TLS-1.3]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", Work in Progress, draft-ietf-tls-tls13-23,
+              January 2018.
+
+
+
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 23]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+Appendix A.  Design Considerations
+
+   This section is not normative.
+
+   The first version of this document was written independently from the
+   October 2013 version of [Email-TLS] ("Recommendations for use of TLS
+   by Electronic Mail Access Protocols").  Subsequent versions merge
+   ideas from both documents.
+
+   One author of this document was also the author of RFC 2595, which
+   became the standard for TLS usage with POP and IMAP, and the other
+   author was perhaps the first to propose that idea.  In hindsight,
+   both authors now believe that that approach was a mistake.  At this
+   point, the authors believe that while anything that makes it easier
+   to deploy TLS is good, the desirable end state is that these
+   protocols always use TLS, leaving no need for a separate port for
+   cleartext operation except to support legacy clients while they
+   continue to be used.  The separate-port model for TLS is inherently
+   simpler to implement, debug, and deploy.  It also enables a "generic
+   TLS load-balancer" that accepts secure client connections for
+   arbitrary foo-over-TLS protocols and forwards them to a server that
+   may or may not support TLS.  Such load-balancers cause many problems
+   because they violate the end-to-end principle and the server loses
+   the ability to log security-relevant information about the client
+   unless the protocol is designed to forward that information (as this
+   specification does for the ciphersuite).  However, they can result in
+   TLS deployment where it would not otherwise happen, which is a
+   sufficiently important goal that it overrides any problems.
+
+   Although STARTTLS appears only slightly more complex than
+   separate-port TLS, we again learned the lesson that complexity is the
+   enemy of security in the form of the STARTTLS command injection
+   vulnerability (Computer Emergency Readiness Team (CERT) vulnerability
+   ID #555316 [CERT-555316]).  Although there's nothing inherently wrong
+   with STARTTLS, the fact that it resulted in a common implementation
+   error (made independently by multiple implementers) suggests that it
+   is a less secure architecture than Implicit TLS.
+
+   Section 7 of RFC 2595 critiques the separate-port approach to TLS.
+   The first bullet was a correct critique.  There are proposals in the
+   HTTP community to address that, and the use of SRV records as
+   described in RFC 6186 resolves that critique for email.  The second
+   bullet is correct as well but is not very important because useful
+   deployment of security layers other than TLS in email is small enough
+   to be effectively irrelevant.  (Also, it's less correct than it used
+   to be because "export" ciphersuites are no longer supported in modern
+   versions of TLS.)  The third bullet is incorrect because it misses
+   the desirable option of "use TLS for all subsequent connections to
+
+
+
+Moore & Newman               Standards Track                   [Page 24]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+   this server once TLS is successfully negotiated".  The fourth bullet
+   may be correct, but it is not a problem yet with current port
+   consumption rates.  The fundamental error was prioritizing a
+   perceived better design based on a mostly valid critique over
+   real-world deployability.  But getting security and confidentiality
+   facilities actually deployed is so important that it should trump
+   design purity considerations.
+
+   Port 465 is presently used for two purposes: for submissions by a
+   large number of clients and service providers and for the "urd"
+   protocol by one vendor.  Actually documenting this current state is
+   controversial, as discussed in the IANA Considerations section.
+   However, there is no good alternative.  Registering a new port for
+   submissions when port 465 is already widely used for that purpose
+   will just create interoperability problems.  Registering a port
+   that's only used if advertised by an SRV record (RFC 6186) would not
+   create interoperability problems but would require all client
+   deployments, server deployments, and software to change
+   significantly, which is contrary to the goal of promoting the
+   increased use of TLS.  Encouraging the use of STARTTLS on port 587
+   would not create interoperability problems, but it is unlikely to
+   have any impact on the current undocumented use of port 465 and makes
+   the guidance in this document less consistent.  The remaining option
+   is to document the current state of the world and support future use
+   of port 465 for submission, as this increases consistency and ease of
+   deployment for TLS email submission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 25]
+
+RFC 8314         Use of TLS for Email Submission/Access     January 2018
+
+
+Acknowledgements
+
+   Thanks to Ned Freed for discussion of the initial concepts in this
+   document.  Thanks to Alexey Melnikov for [POP3-over-TLS], which was
+   the basis of the POP3 Implicit TLS text.  Thanks to Russ Housley,
+   Alexey Melnikov, and Dan Newman for review feedback.  Thanks to
+   Paul Hoffman for interesting feedback in initial conversations about
+   this idea.
+
+Authors' Addresses
+
+   Keith Moore
+   Windrock, Inc.
+   PO Box 1934
+   Knoxville, TN  37901
+   United States of America
+
+   Email: moore@network-heretics.com
+
+
+   Chris Newman
+   Oracle
+   440 E. Huntington Dr., Suite 400
+   Arcadia, CA  91006
+   United States of America
+
+   Email: chris.newman@oracle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Newman               Standards Track                   [Page 26]
+