Internet DRAFT - draft-moore-email-tls
draft-moore-email-tls
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]
