[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                 K. Moore
Internet-Draft                                          Network Heretics
Intended status: Standards Track                        October 21, 2013
Expires: April 24, 2014


   Recommendations for use of TLS by Electronic Mail Access Protocols
                        draft-moore-email-tls-00

Abstract

   This memo requires support for Transport Layer Security (TLS) in all
   electronic mail user agents (MUAs) and the servers with which they
   communicate when using standard protocols, including Interactive
   Message Access Protocol (IMAP), Post Office Protocol (POP) and the
   variant of the Simple Message Transfer Protocol (SMTP) used in
   message submission.  It also requires support for TLS in mail
   protocol servers provided by electronic mail service providers, and
   encourages mail service providers to migrate to requiring TLS for all
   interaction with their servers.  In addition, this memo details
   specific recommendations for implementation and use of TLS with
   electronic mail protocols used in interactions between MUAs and mail
   service providers.

   Use of TLS with SMTP for message relaying is described in a separate
   document, and not in scope for this document.

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 24, 2014.




Moore                    Expires April 24, 2014                 [Page 1]


Internet-Draft          Email TLS Recommendations           October 2013


Copyright Notice

   Copyright (c) 2013 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
   (http://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Goals and Rationale . . . . . . . . . . . . . . . . . . .   5
     1.3.  Approach  . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.  Implementation Requirements . . . . . . . . . . . . . . . . .   8
     2.1.  Mail Server Requirements  . . . . . . . . . . . . . . . .   8
     2.2.  Mail User Agent Requirements  . . . . . . . . . . . . . .   9
       2.2.1.  MUAs Configurable to Require TLS  . . . . . . . . . .   9
       2.2.2.  Non-configurable MUAs and nonstandard access
               protocols . . . . . . . . . . . . . . . . . . . . . .   9
       2.2.3.  Implicit TLS vs. STARTTLS . . . . . . . . . . . . . .  10
       2.2.4.  Use of SRV records in Establishing Configuration  . .  10
       2.2.5.  Manual configuration of MUA connection to servers . .  11
       2.2.6.  Verification of new or edited server configurations .  11
       2.2.7.  Downgrading of TLS-required Configurations  . . . . .  12
       2.2.8.  Requirements for MUA use of TLS . . . . . . . . . . .  12
       2.2.9.  Use of SMTP by MUAs for other than mail submission  .  13
       2.2.10. Other network-accessible services used by MUAs  . . .  13
       2.2.11. Additional Considerations for Webmail and other
               Split-MUA Clients . . . . . . . . . . . . . . . . . .  14
       2.2.12. Use of DANE by MUAs . . . . . . . . . . . . . . . . .  14
       2.2.13. Use of DNSSEC . . . . . . . . . . . . . . . . . . . .  15
     2.3.  Requirements Common To Both Servers and MUAs  . . . . . .  16
   3.  Mail Service Provider Requirements  . . . . . . . . . . . . .  16
     3.1.  Server Requirements . . . . . . . . . . . . . . . . . . .  16
     3.2.  MSPs MUST provide Submission Servers  . . . . . . . . . .  16
     3.3.  TLS Server Certificate Requirements . . . . . . . . . . .  16
     3.4.  Recommended DNS records for mail protocol servers . . . .  17
       3.4.1.  MX records  . . . . . . . . . . . . . . . . . . . . .  17
       3.4.2.  SRV records . . . . . . . . . . . . . . . . . . . . .  17
       3.4.3.  TLSA records  . . . . . . . . . . . . . . . . . . . .  17



Moore                    Expires April 24, 2014                 [Page 2]


Internet-Draft          Email TLS Recommendations           October 2013


       3.4.4.  DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  18
     3.5.  MSP Server Monitoring . . . . . . . . . . . . . . . . . .  18
     3.6.  Encourage Transition to TLS Required Configurations . . .  18
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  21

1.  Introduction

   Most Internet electronic mail protocols, including SMTP Submission
   Protocol [RFC4409], Interactive Message Access Protocol (IMAP)
   [RFC3501], and Post Office Protocol (POP) [RFC1939], were originally
   designed to transmit all authentication credentials, commands, and
   application data in cleartext only.  At the time that those protocols
   were originally designed, encryption was computationally expensive,
   and/or not widely available due to export limitations and other
   constraints.  In the earliest days of these protocols, it was also
   typical that Internet service was provided through hardwired hosts
   and networks, which provided some degree of security against
   eavesdropping by limiting physical access to the server hosts and
   network media.

   Recently it has become apparent that the potential for eavesdropping
   of electronic mail traffic has increased for a variety of reasons,
   including: "rogue" wireless LAN access points that monitor traffic,
   industrial espionage, and government-supported espionage by a variety
   of governments.  For these reasons it now seems prudent to recommend
   a much wider use of TLS encryption than has been conventional in the
   past.

   In brief, this memo now recommends that:

   o  TLS on a well-known port ("Implicit TLS") be for supported for
      Interactive Message Access Protocol (IMAP), Post Office Protocol
      (POP), and SMTP Submission protocol for all electronic mail user
      agents and servers;

   o  Electronic mail user agents (MUAs) require TLS for all newly
      configured connections to servers, unless explicitly configured by
      their users to not require TLS;

   o  When explicitly configuring an MUA to not require TLS, the MUA
      warn users that their mail traffic is insecure;

   o  Electronic mail service providers (MSPs) support use of Implicit
      TLS for IMAP, POP, and SMTP Submission; and



Moore                    Expires April 24, 2014                 [Page 3]


Internet-Draft          Email TLS Recommendations           October 2013


   o  MSPs encourage new users to configure their MUAs to require TLS
      when connecting to their servers, and encourage existing users to
      transition to MUA configurations that require TLS, using
      mechanisms appropriate for their user communities.

   This document therefore defines profiles of the above protocols which
   impose additional requirements beyond those in the base protocol
   specifications.  Specific details of these requirements, and
   additional requirements, are outlined below.

1.1.  Definitions

   Implicit TLS - The practice of automatically negotiating a TLS layer
   as soon as a TCP connection is established between client and server,
   on a TCP port configured on that server to perform such negotiation.
   This port may be assigned by IANA for that purpose, advertised by DNS
   SRV record, or used by private agreement between client and server.
   (See also STARTTLS mechanism)

   Interactive Message Access Protocol (IMAP) - The protocol defined in
   [RFC3501] which is used for accessing and managing received
   electronic mail.  This memo will also refer to "IMAP client" and
   "IMAP server" when appropriate.

   mail account - A set of services provided by a Mail Service Provider
   for a particular sender and/or recipient, which may include (among
   others): mail submission, access to delivered mail, management of
   delivered mail, configuration of incoming mail filters, management of
   authentication credentials.  A mail account will generally be
   implemented with a variety of protocol servers, for example IMAP,
   POP, Submission, and/or a webmail service, but will usually share a
   common set of authentication credentials across all of those servers.

   Mail User Agent (MUA) - A client that performs one or more of the
   following: (a) submits electronic mail for delivery, (b) accesses
   mail delivered to one or more mailboxes, and/or (c) manages mail
   delivered to one or more mailboxes, on behalf of one or more (human
   or nonhuman) users.  An MUA may function as any of an IMAP client,
   POP client, Submission client, or SMTP client, among other roles.

   Mail Service Provider (MSP) - A provider of electronic mail services
   including (a) submission of outgoing mail and/or (b) acceptance of
   incoming mail and providing recipients with the ability to access
   that mail.  In this memo, the term Mail Service Provider applies not
   only to providers that offer such services to the public (whether for
   "free" or in exchange for monetary renumeration), but also to
   providers of mail services to private communities, including business
   enterprises.



Moore                    Expires April 24, 2014                 [Page 4]


Internet-Draft          Email TLS Recommendations           October 2013


   Opportunistic TLS - The practice of negotiating TLS when it appears
   to a TLS-capable client that the server also supports TLS, but
   continuing the intended operation in cleartext when it appears to the
   client that the server does not support TLS.

   pinning - The act of establishing a cached name association between
   the application service's certificate and one of the client's
   reference identifiers, whether or not any of the certificate's
   presented identifiers matches one of the client's reference
   identifiers.  (See also section 1.8 of [RFC6125].)

   Post Office Protocol (POP) - The protocol defined in [RFC1939] which
   is used for accessing and managing received electronic mail.  Since
   POP is a client-server protocol, this memo will refer to POP client
   and POP server when appropriate.

   presented identifier - Any of the identifiers presented to a client
   in a validated TLS server certificate.  (See also section 1.8 of
   [RFC6125].)

   reference identifier - Any of a set of identifiers pre-determined by
   a TLS client to be acceptable identifiers for a particular service,
   to be matched against the presented identifiers from the server's
   certificate.  (See also section 1.8 of [RFC6125].)

   STARTTLS mechanism - One of the protocol extensions defined in
   [RFC2595] or [RFC3207] for negotiating TLS after a cleartext
   application layer connection between client and server have already
   been established.  (See also Implicit TLS.)

   Submission protocol - the variant of SMTP defined in [RFC6409] and
   used exclusively for submission of outgoing messages by MUAs.

   Transport Layer Security (TLS) - The protocol defined in [RFC5246]
   and its revisions for providing security services over a TCP stream.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Goals and Rationale

   This memo is one of several with the shared goal of encouraging use
   of strong encryption for all uses of Internet electronic mail
   protocols, and thus reducing the effectiveness of mass surveillance
   which is known to be conducted on a large scale by several parties.
   Other memos address other aspects of this problem, including
   opportunistic encryption for relayed mail using SMTP



Moore                    Expires April 24, 2014                 [Page 5]


Internet-Draft          Email TLS Recommendations           October 2013


   [I-D.ietf-dane-smtp-with-dane], and improving TLS server identity
   checks [I-D.melnikov-email-tls-certs].

   The primary goal for this memo is to encourage a much wider adoption
   of reliable encryption for email protocol traffic between Mail User
   Agents (MUAs) and mail servers.  "Reliable encryption" means that a
   user can have confidence that his mail traffic is securely encrypted
   when it travels over the network.  By contrast, if the traffic is not
   encrypted, the user should be made explicitly aware of this.  Since
   TLS is the Internet standards-track encryption mechanism which is
   most widely implemented in email clients and servers, is well-
   maintained, and believed to be sufficiently extensible to accommodate
   newly identified threats and use cases, TLS is the mechanism
   specified for providing such a reliable encryption service.

   Note: The goal of "reliable encryption" is a distinct goal from, and
   in contrast with, a goal to encrypt as much traffic as possible.
   Encrypting as much traffic as possible could be accomplished using
   Opportunistic TLS.  However, this would not be the same as "reliable
   encryption", as it would not provide the user with assurance that his
   traffic is encrypted.  It also appears that there are several ways in
   which Opportunistic TLS can easily be defeated by an attacker.  So
   while in some sense encrypting as much traffic as possible is also a
   worthy goal, reliable encryption appears to be more important.  Only
   reliable encryption provides protection in the case of an active
   attack.

   In furtherance of the goal of reliable encryption, a number of new
   requirements are imposed on mail protocol engines.  However, an
   additional goal of this memo is to facilitate continued operation
   between legacy clients and servers that meet the requirements in this
   memo, and between legacy servers and clients that meet the
   requirements in this memo.  Another part of that goal is to
   facilitate such continued operation while providing an "upgrade path"
   such that the vast majority of clients and servers should be able to
   be modified to meet these requirements within a short time, without
   disruption of service or significant support costs.

   An additional goal of this memo is to discourage exposure of reusable
   authentication credentials (such as passwords) over an unencrypted
   channel when using IMAP, POP, or SMTP Submission, or any other
   protocol for which the same credentials are used as with one of the
   above protocols.

   It is explicitly not a goal of this memo to provide any assurance of
   either end-to-end encryption (from submission to delivery), or
   encryption of delivered email that has been stored in a mailbox.
   Unless additionally encrypted by other means such as S/MIME



Moore                    Expires April 24, 2014                 [Page 6]


Internet-Draft          Email TLS Recommendations           October 2013


   [RFC3369], email messages will still be available in cleartext on
   each client and server that processes or stores those messages.

1.3.  Approach

   The basic approach is to recommend that TLS and the Implicit TLS
   mechanism be used for all interactions between MUAs and servers: that
   all MUAs and servers support TLS and Implicit TLS, that MUAs use TLS
   by default for all newly configured server connections unless
   explicitly configured otherwise by their users, and that mail service
   providers encourage existing clients to upgrade to MUAs that support
   TLS and upgrade existing MUA configurations to require TLS.

   After much consideration, TLS over a well-known port ("Implicit TLS")
   is recommended instead of the STARTTLS mechanism, for the following
   reasons:

   o  It appears to be the desired end-state.  In a future world where
      TLS were always used, there would no longer be a need for the
      STARTTLS mechanism.  Even if it were still necessary for some MSPs
      to continue to support cleartext operation for legacy or very
      lightweight clients, all MUAs capable of using TLS could
      eventually be expected to migrate to configurations using Implicit
      TLS.

   o  Implicit TLS capability is discoverable using SRV records as
      described in [RFC6186], whereas discovering STARTTLS capability
      requires opening a connection to the server.

   o  Use of Implicit TLS appears to be less susceptible to both MUA
      misconfiguration and to unintended downgrading to cleartext
      operation, even for legacy MUAs.  If an MUA's configuration
      explicitly specifies either use of TLS or use of the well-known
      port assigned by IANA for use with Implicit TLS (often termed the
      "SSL port"), it seems unlikely that the MUA will downgrade to the
      "non-SSL port" under any circumstances, even if the server is
      unreachable or TLS negotiation fails.  In addition, if a mail
      service provider advertises Implicit TLS as its preferred
      mechanism to connect to servers (via SRV records and/or human-
      readable documentation), the mail service provider can defeat
      automatic downgrading to cleartext operation by MUAs (even with
      legacy MUAs) simply by not providing a working server that
      supports cleartext operation on the same IP address recommended
      for use with new configurations.  (Cleartext access for existing
      users and configurations can still be maintained on the existing
      IP address.)





Moore                    Expires April 24, 2014                 [Page 7]


Internet-Draft          Email TLS Recommendations           October 2013


   o  In earlier unpublished drafts of this memo, the author attempted
      to recommend STARTTLS in preference to Implicit TLS.  The ability
      of the same server to support both TLS and cleartext operation
      seemed to conflict with the desire for a server to be able to
      disable cleartext operation for new users or users who had
      migrated to require TLS.  It was found difficult to describe how
      servers requiring TLS for some users and permitting cleartext
      access for others, could do so without introducing the possibility
      for MUAs to expose the user's username and password in cleartext
      even when that user was required to use TLS - because with most of
      the password-based authentication mechanisms defined for these
      protocols, the server does not have the opportunity to refuse an
      authentication attempt until the user's password has been
      transmitted.  Rather than recommend STARTTLS or allow either
      mechanism, it seemed simpler and less error-prone to just specify
      Implicit TLS as the required and recommended TLS negotiation
      mechanism for new MUA-to-server configurations.

2.  Implementation Requirements

   This section details requirements for implementations of electronic
   mail protocol clients and servers.  Note that a requirement for a
   client or server implementation to support a particular feature is
   not the same thing as a requirement that a client or server running a
   conforming implementation be configured to use that feature.
   Requirements for MSPs are distinct from requirements for protocol
   implementations, and are listed in a separate section.

2.1.  Mail Server Requirements

   The following requirements apply to IMAP, POP, and Submission server
   implementations:

   All IMAP, POP, and Submission servers MUST be configurable to support
   the use of TLS and the Implicit TLS mechanism when communicating with
   MUAs.

   IMAP, POP, and Submission servers SHOULD also support the STARTTLS
   mechanism for the sake of backward compatibility with existing MUAs
   and configurations that use it.

   Servers which support STARTTLS SHOULD be capable of requiring TLS
   before performing any operation other than capability discovery and
   STARTTLS.







Moore                    Expires April 24, 2014                 [Page 8]


Internet-Draft          Email TLS Recommendations           October 2013


   IMAP, POP, and Submission servers which support STARTTLS SHOULD be
   capable of disabling STARTTLS operation and/or disabling operation on
   any port that isn't configured to use Implicit TLS, so that the
   service provider may force all users to use Implicit TLS.

2.2.  Mail User Agent Requirements

   This section describes requirements on Mail User Agents (MUAs) using
   IMAP, POP, and/or Submission protocols.

   Note: Requirements pertaining to use of Submission servers are also
   applicable to use of SMTP servers (whether on port 25 or on another
   port as advertised by a SRV record with _smtp._tcp or _smtps._tcp
   label) for mail submission.

2.2.1.  MUAs Configurable to Require TLS

   MUAs which are configurable to communicate with user-specified IMAP,
   POP, and/or Submission servers MUST be configurable (on a per-server
   or per-account basis) to require the use of TLS when communicating
   with those servers.

   MUAs MAY also be configurable (on a per-server or per-account basis)
   to use Opportunistic TLS when connecting to IMAP, POP, and Submission
   servers.  Such a configuration MUST NOT be the default.  Note that
   support for an Opportunistic TLS configuration option does not
   satisfy the requirement that MUAs be able to require use of TLS when
   communicating with a particular server.

   In addition, MUAs MAY be configurable (on a per-server or per-account
   basis) to not use TLS, to permit it to interoperate with legacy
   servers that do not support TLS.

   Whenever requested to establish any configuration that does not
   require TLS to talk to a server or account (including a configuration
   using Opportunistic TLS), an MUA SHOULD warn its user that his or her
   mail traffic (including password, if applicable) will be exposed to
   attackers.

2.2.2.  Non-configurable MUAs and nonstandard access protocols

   MUAs which are not configurable to use user-specified servers MUST
   use TLS or similarly other strong encryption mechanism when
   communicating with their mail servers.  This generally applies to
   MUAs that are pre-configured to operate with one or more specific
   services, whether or not supplied by the vendor of those services.





Moore                    Expires April 24, 2014                 [Page 9]


Internet-Draft          Email TLS Recommendations           October 2013


   MUAs using protocols other than IMAP, POP, and Submission to
   communicate with mail servers, MUST use TLS or other similarly robust
   encryption mechanism in conjuction with those protocols.

2.2.3.  Implicit TLS vs. STARTTLS

   User-configurable MUAs MUST support the ability to use the Implicit
   TLS mechanism when communicating with servers that support it.

   User-configurable MUAs SHOULD also support the STARTTLS mechanism for
   the sake of backward compatibility with IMAP, POP, and Submission
   servers that do not support Implicit TLS with these services.

2.2.4.  Use of SRV records in Establishing Configuration

   User-configurable MUAs SHOULD support use of [RFC6186] to determine
   (for mail service providers that advertise such information) which
   options are available for configuration of connections to IMAP, POP,
   and Submission servers.  However, when using configuration
   information obtained by this method, MUAs SHOULD behave as if the
   user had explicitly required TLS, unless the user has explicitly
   requested to disable it.  (Compare with section 6 of [RFC6186]).
   This will have the effect of causing the MUA to ignore advertised
   configurations which do not support TLS, even when those advertised
   configurations have a higher priority than other advertised
   configurations.  (The specific user interface by which a user
   requests to disable encryption is an implementation detail, but the
   user interface should make it clear to users that disabling
   encryption will likely result in their email being spied upon.)
   Note: [RFC6186] does not define a label for use with SRV records to
   indicate that a Submission server supports Implicit TLS on a
   particular port.  This memo defines the _submissions._tcp label for
   that purpose.

   When using [RFC6186] configuration information, Mail User Agents
   SHOULD NOT automatically establish new configurations which 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.)

   When establishing a new configuration for connecting to an IMAP, POP,
   or Submission server, an MUA MUST NOT blindly trust SRV records



Moore                    Expires April 24, 2014                [Page 10]


Internet-Draft          Email TLS Recommendations           October 2013


   unless they are signed by DNSSEC and have a valid signature.
   Instead, the MUA SHOULD warn the user that the DNS-advertised
   mechanism for connecting to the server is not authenticated, and
   request the user to manually verify the connection details by
   reference to his or her mail service provider's documentation.

   Similarly, 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.  However, MUAs SHOULD NOT automatically upgrade
   configurations to require TLS without explicit user approval.

2.2.5.  Manual configuration of MUA connection to servers

   Configurable MUAs SHOULD permit manual user configuration and re-
   configuration of server name or address, port number, and whether to
   use STARTTLS and/or Implicit TLS, for IMAP, POP, and Submission
   servers, regardless of any information obtained using [RFC6186]
   procedures or other means.

   Note: While many users will always use the IMAP or POP and Submission
   servers provided by the same MSP to which their incoming mail is
   delivered, there are many valid use cases for having these servers
   provided by multiple parties.  It is therefore useful for an MUA to
   permit users to configure each of those services separately.

   If a user explicitly selects a configuration for a server that does
   not use TLS, the MUA SHOULD, prior to authenticating to the server as
   that user, warn the user that traffic to the server will not be
   encrypted and thus will 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 use of mass surveillance).

   Whenever a MUA is explicitly configured to connect to a specific IP
   address rather than a DNS name, the MUA MUST also either be
   configured to explicitly compare the server certificate against a
   known certificate ("pinning"), or be explicitly configured as to
   which reference identifier(s) will be matched with the TLS server
   certificate's presented identifiers.

2.2.6.  Verification of new or edited server configurations





Moore                    Expires April 24, 2014                [Page 11]


Internet-Draft          Email TLS Recommendations           October 2013


   Any time the configuration of an MUA is altered to change the servers
   with which the MUA communicates, the MUA SHOULD verify that it can
   connect to the servers, validate the TLS certificates, compare them
   with TLSA records if those are present and have valid DNSSEC
   signatures, and authenticate to the servers on behalf of the user.

   If TLSA verification of the server's public key fails the MUA should
   not attempt to authenticate to the server.

   If the server's TLS certificate does not present any identifiers that
   match any of the appropriate reference identifiers for the server
   name, the MUA MAY offer to "pin" the server certificate for use in
   future comparisons.  In such cases the MUA SHOULD instruct the user
   to check with the MSP to determine whether the MSP thinks that it has
   a valid certificate that is issued by a trusted certificate
   authority, before the user approves the configuration that "pins" the
   certificate.

2.2.7.  Downgrading of TLS-required Configurations

   Once a configuration that requires TLS to connect to a server has
   been established, Mail User Agents MUST NOT attempt to authenticate
   to that server, or use that server for mail submission, without
   successfully negotiating TLS (including server certificate validity
   checks and reference identifier matching checks), unless the user has
   explicitly reconfigured the MUA to do so.

   An MUAs configured to use STARTTLS for a particular server SHOULD
   warn its user when a server which previously advertised STARTTLS
   capability is apparently no longer doing so, but MUST NOT downgrade
   the connection to cleartext unless explicitly (re)configured by the
   user to do so.

2.2.8.  Requirements for MUA use of TLS

   An MUA configured to require TLS when connecting to a particular
   server MUST successfully negotiate TLS (including successful
   certificate validity and reference identifier checks) before
   attempting to use that server.  The TLS layer MAY use either Implicit
   TLS or STARTTLS, according to the client's configuration for that
   server.










Moore                    Expires April 24, 2014                [Page 12]


Internet-Draft          Email TLS Recommendations           October 2013


   An MUA that is configured to require TLS for a particular server MUST
   negotiate TLS (including successful certificate validity and
   reference identifier checks) before attempting to authenticate to
   that server.  This TLS layer MAY be negotiated using either Implicit
   TLS or the STARTTLS mechanism, according to the client's
   configuration for that server.  Note: This requirement applies even
   if the authentication mechanism doesn't use cleartext credentials.

   MUAs MUST abort the connection and refuse to interact with any server
   for which TLS negotiation signals any of the alert messages specified
   in section 7.2 of [RFC5246], or any other indication that the
   connection may be insecure (whether due to man-in-the-middle attack
   or other reason).  Exception: Connections to a server with a self-
   signed certificate MAY be accepted if the Mail User Agent is
   explicitly configured ("pinned") to accept a self-signed certificate
   for that server.

   MUAs MUST use the procedure defined in [RFC6125] to determine whether
   a server's TLS certificate contains an identifier which matches the
   DNS name to which the MUA is attempting to connect, and MUST abort
   the TLS session if the server's certificate does not present an
   identifier that matches one of the MUA's predetermined reference
   identifiers for that server.

   It is important to avoid using DNS names obtained from SRV records
   (rather than from explicit user configuration) as reference
   identifiers when comparing with presented identifiers in TLS server
   certificates, unless those SRV records were signed with DNSSEC and
   the signatures were verified by the MUA.

   Note in Draft: [I-D.melnikov-email-tls-certs] describes a profile of
   [RFC6125] for use in MUA checking of presented identifiers in TLS
   server certificates.

2.2.9.  Use of SMTP by MUAs for other than mail submission

   Some Mail User Agents use SMTP for purposes other than submitting
   mail, e.g. to determine whether a particular recipient can receive a
   message of a particular size.  Such uses SHOULD use TLS if the server
   advertises STARTTLS in response to EHLO.

   To avoid exposing message metadata which could be used for traffic
   analysis, MUAs SHOULD NOT send MAIL or RCPT to an SMTP server without
   negotiating TLS.

2.2.10.  Other network-accessible services used by MUAs





Moore                    Expires April 24, 2014                [Page 13]


Internet-Draft          Email TLS Recommendations           October 2013


   MUAs which are configured to access other services requiring
   authentication, and using the same reusable credentials (e.g.
   passwords) with those servers as are used to authenticate to servers
   using TLS, MUST NOT expose those credentials over an unencrypted
   connection.

2.2.11.  Additional Considerations for Webmail and other Split-MUA
         Clients

   A webmail MUA is any MUA that is designed to be used via a web
   browser.  Typically a webmail MUA has two portions - a "front-end"
   portion which runs in the user's web browser, and a "back-end" which
   runs on a web server.  The webmail MUA typically uses HTTP to
   communicate between the front-end and back-end, and the back-end is
   responsible for communicating with message stores and mail submission
   services.  Other "split MUA" arrangements also exist, notably to
   support mobile and other devices with modest local compute capability
   and/or bandwidth limitations.

   The above requirements are also applicable to Webmail and other split
   MUA arrangements.  For example, the requirements listed above for use
   of TLS between IMAP, POP, and Submission clients and servers also
   apply to communications between the back-ends of split MUAs and
   servers for those protocols.  If the communications between the back-
   end of a split MUA and those servers doesn't use TLS, it MUST use a
   similarly-secure encryption mechanism.

   In addition, split MUAs MUST use TLS or a similarly-secure encryption
   mechanism, to communicate between the front-end (web browser in the
   case of a webmail MUA) and the back-end.

2.2.12.  Use of DANE by MUAs

   MUAs SHOULD be able to use the DANE TLSA records in DNS [RFC6698] to
   verify that the public key presented in a certificate ostensibly
   received from a server, is actually a key authorized for use by that
   domain name.  Use of TLSA records can provide a trust anchor in
   addition to that provided by the TLS server certificate, and help
   protect against rogue certificate authorities and compromised
   certificate authority private keys.  There are multiple cases which
   must be considered:










Moore                    Expires April 24, 2014                [Page 14]


Internet-Draft          Email TLS Recommendations           October 2013


   o  No TLSA record for the target domain exists.  In this case
      verification of the server's certificate SHOULD rely entirely on
      whether the signing certificate authority is trusted by the client
      or whether the client has been explicitly configured ("pinned") to
      trust that particular certificate.  However a MUA MAY be
      configurable to require both a signed TLSA record and a TLS server
      certificate signed by a trusted certificate authority.

   o  One or more TLSA records exist for the target domain but are
      either unsigned, or the DNSSEC signature is invalid, or DNSSEC
      signature cannot be verified.  In this case the client SHOULD
      refuse to connect to the server until the signature on the TLSA
      records can be verified, unless the client has been explicitly
      configured ("pinned") to trust a particular server certificate.
      This might either be an indication of an attack or a configuration
      error, but seems better to detect the configuration error and
      cause it to be fixed, than ignore it.

   o  One or more TLSA records exist and have a valid DNSSEC signature
      but no TLSA records match the X.509 certificate presented by the
      server.  In this cases the client MUST gracefully terminate the
      session with the server without attempting to authenticate or
      request services, as this may indicate a man-in-the-middle attack.

   o  TLSA record exists and has a valid DNSSEC signature, and the
      public key specified in a TLSA record matches the public key in
      the X.509 certificate presented by the server.  However, the
      server certificate is not signed by a trusted certificate
      authority, nor has the MUA been explicitly configured ("pinned")
      to accept that particular certificate.  In this case the
      connection MUST gracefully terminate the session with the server
      without attempting to authenticate or request services.

   o  The TLSA record has a valid DNSSEC signature, TLS has been
      successfully negotiated with no errors or alerts, and the server's
      certificate is valid and signed by a trusted certificate
      authority.  In this case the session MAY proceed.

2.2.13.  Use of DNSSEC

   All uses of DNSSEC by MUAs (including use of SRV and TLSA records)
   SHOULD explicitly verify the chain of DNSSEC signatures from the
   root, rather than trusting a recursive caching DNS name server to do
   so.  It is acceptable to obtain RRSIG, DNSKEY, DS, etc., resource
   records from a recursive caching name server.  But a recursive
   caching name server SHOULD NOT be assumed to be trustworthy enough to
   validate signatures.




Moore                    Expires April 24, 2014                [Page 15]


Internet-Draft          Email TLS Recommendations           October 2013


2.3.  Requirements Common To Both Servers and MUAs

   TLS version 1.2 [RFC5246] SHOULD be supported.

   Per [RFC6176], SSL version 2.0 MUST NOT be supported.  MUAs MUST
   either disable SSL 2.0 support in their TLS implementations or
   immediately close a connection with a server if SSL 2.0 is
   negotiated.  Servers MUST NOT advertise support for version 2.0 of
   SSL.

   The renegotiation indication extension described in [RFC5746] SHOULD
   be supported.

   The Server Name Indication extension [RFC6066] SHOULD be supported.

3.  Mail Service Provider Requirements

3.1.  Server Requirements

   Mail Service Providers MUST use server implementations that conform
   to this specification.

3.2.  MSPs MUST provide Submission Servers

   Mail Service Providers which accept incoming mail for delivery using
   the Internet Protocol MUST provide one or more Submission servers for
   this purpose, separate from the SMTP servers used to process incoming
   mail.  Those submission servers MUST be configured to support
   Implicit TLS and MAY be configured to support STARTTLS also.

   MSPs MAY also support submission of messages via one or more
   designated SMTP servers to facilitate compatibility with existing MUA
   configurations and legacy MUAs.

   Discussion: SMTP servers used to accept incoming mail or to relay
   mail are expected to accept mail in cleartext.  This is incompatible
   with the purpose of this memo which is to encourage encryption of
   traffic between mail servers.  There is no such requirement for
   Submission servers to accept mail in cleartext or without
   authentication.  For other reasons, use of separate Submission
   servers has been best practice for many years.

   Submission servers SHOULD require authentication as a condition of
   accepting mail.

3.3.  TLS Server Certificate Requirements





Moore                    Expires April 24, 2014                [Page 16]


Internet-Draft          Email TLS Recommendations           October 2013


   MSPs MUST maintain valid server certificates for all servers.  Those
   server certificates MUST present DNS-IDs and SRV-IDs conforming to
   [RFC6125] and which will be recognized by MUAs meeting the
   requirements of this memo.  In addition, those server certificates
   MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for
   compatibility with legacy MUAs.

   A single certificate MAY be used for multiple electronic mail
   protocol servers (including webmail) which all providing service for
   a particular mail domain, but use of the same certificate for
   services other than electronic mail is discouraged.

   If a protocol server provides service for more than one mail domain,
   its server certificates MAY advertise 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 extension to TLS.

3.4.  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.

3.4.1.  MX records

   It is recommended that MSPs advertise MX records for handling of
   inbound mail (instead of relying entirely on A or AAAA records), and
   that those MX records be signed using DNSSEC.  This is mentioned here
   only for completeness, as handling of inbound mail is out of scope
   for this document.

3.4.2.  SRV records

   MSPs SHOULD advertise SRV records to aid MUAs in determination of
   proper configuration of servers, per the instructions in [RFC6186].

   MSPs SHOULD advertise servers that support Implicit TLS in preference
   to those which support cleartext and/or STARTTLS operation.

3.4.3.  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.





Moore                    Expires April 24, 2014                [Page 17]


Internet-Draft          Email TLS Recommendations           October 2013


3.4.4.  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.

3.5.  MSP Server Monitoring

   MSPs SHOULD regularly and frequently monitor their various servers to
   make sure that: TLS server certificates remain valid and are not
   about to expire, TLSA records match the public keys advertised in
   server certificates and are signed using DNSSEC, server
   configurations are consistent with SRV advertisements, and DNSSEC
   signatures are valid and verifiable.  Failure to detect expired
   certificates and DNS configuration errors in a timely fashion can
   result in significant loss of service for an MSP's users.

3.6.  Encourage Transition to TLS Required Configurations

   Mail Service Providers SHOULD encourage their users to transition to
   requiring TLS for communications with their servers.

   Each MSP must determine which transition measures are most
   appropriate for its own user community.  Possible mechanisms include,
   but are not limited to: using [RFC6186] to advertise servers which
   implement Implicit TLS; allowing individual users to configure their
   accounts so that the servers will refuse their authentication unless
   using TLS; requiring new users to always use TLS; providing or
   recommending MUA implementations that implement TLS and the ability
   to require TLS.

   Note: there is a tradeoff here between encouraging use of TLS and not
   breaking access for existing users or users with legacy mail clients.
   Whether to enable "TLS required" for all users, new users only, or
   particular users that have expressed a preference to always use TLS,
   is a policy decision which should be re-evaluated periodically as
   conditions change - e.g. as more clients are upgraded to support TLS
   and [RFC6186].  Similarly, whether and when to require existing users
   to use TLS (and perhaps to upgrade their mail clients) is a policy
   decision that will differ from one service provider to the next
   depending on conditions and business needs.

4.  Security Considerations

   This entire memo is about security considerations.

   The mechanisms in this memo are intended to address certain specific
   identified threats, including:




Moore                    Expires April 24, 2014                [Page 18]


Internet-Draft          Email TLS Recommendations           October 2013


   o  A downgrading attack by thwarting connection to or TLS negotiation
      on the "SSL port", by a MUA implementing Opportunistic TLS.  This
      is addressed by encouraging MUAs to implement "TLS required"
      operation so that the MUA will not downgrade.

   o  Compromised certificate authority private keys, and rogue
      certificate authority issuing certificates to impersonators, to
      generate fake certificates that can be used with man-in-the-middle
      attacks.  This is addressed by encouraging support for DNSSEC-
      signed TLSA records in both clients and servers, thus providing an
      additional trust anchor beyond the TLS server certificate.

   o  An interception proxy, firewall, or other middlebox hiding
      STARTTLS capability advertisement or blocking the STARTTLS
      command, thus forcing a downgrade.  This is addressed by
      encouraging MUAs to support "TLS required" configurations and
      users to migrate to them, as well as by encouraging Implicit TLS
      in preference to STARTTLS.

   o  Attacks on DNS queries, including cache poisoning, man-in-the-
      middle, and forged responses.  These are addressed by encouraging
      use of DNSSEC and by insisting on strict verification of presented
      identifiers obtained from TLS server certificates against a
      predetermined set of reference identifers that are based either on
      explicit user input or DNSSEC-signed DNS responses.

   In exchange for the perceived benefits listed above, the mechanisms
   described in this memo may increase the vulnerability of mail
   services to denial-of-service attacks.  This appears to be a
   necessary and appropriate compromise.

   Use of TLS is not a substitute for end-to-end encryption such as S/
   MIME.  In particular, TLS does not and cannot protect against
   compromise of the message servers that see the messages in cleartext.
   Users are encouraged to use end-to-end encryption whenever available.

5.  IANA Considerations

   IANA is requested to allocate a well-known port for use with a
   Submission protocol server configured to use Implicit TLS.  The
   recommended service identifier for this port is "submissions", for
   consistency with identifiers for other "SSL ports", even though this
   looks like a plural.

   If there is a registry of labels for SRV records, IANA is requested
   to define a label of _submissions._tcp for use in advertising
   Submission servers using Implicit TLS.




Moore                    Expires April 24, 2014                [Page 19]


Internet-Draft          Email TLS Recommendations           October 2013


6.  References

6.1.  Normative References

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
              2595, June 1999.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 4409, April 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, February 2010.

   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
              Extension Definitions", RFC 6066, January 2011.

   [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, March 2011.

   [RFC6176]  Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
              (SSL) Version 2.0", RFC 6176, March 2011.

   [RFC6186]  Daboo, C., "Use of SRV Records for Locating Email
              Submission/Access Services", RFC 6186, March 2011.

   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, RFC 6409, November 2011.





Moore                    Expires April 24, 2014                [Page 20]


Internet-Draft          Email TLS Recommendations           October 2013


   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

6.2.  Informative References

   [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
              3369, August 2002.

   [I-D.melnikov-email-tls-certs]
              Melnikov, A., "Updated TLS Server Identity Check Procedure
              for Email Related Protocols", draft-melnikov-email-tls-
              certs-01 (work in progress), October 2013.

   [I-D.ietf-dane-smtp-with-dane]
              Dukhovni, V. and W. Hardaker, "SMTP security via
              opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-00
              (work in progress), October 2013.

Author's Address

   Keith Moore
   Network Heretics
   PO Box 1934
   Knoxville, TN  37901
   United States

   EMail: moore@network-heretics.com























Moore                    Expires April 24, 2014                [Page 21]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/