Deployable Enhanced Email Privacy (DEEP)Network HereticsPO Box 1934KnoxvilleTNUS37901moore@network-heretics.comOracle440 E. Huntington Dr., Suite 400ArcadiaCA91006USchris.newman@oracle.com
Applications
I-DInternet-Draft
This specification defines a set of requirements and facilities designed
to improve email privacy. This provides mechanisms intended to increase
use of already deployed Transport Layer Security (TLS) technology,
provide a model for mail user agent's confidentiality assurance, and
enable mail service providers to advertise improved TLS privacy
facilities.
Software that provides email service via Internet Message Access
Protocol (IMAP) , Post Office Protocol (POP)
and/or Simple Mail Transfer Protocol (SMTP)
Submission usually has Transport Layer Security
(TLS) support but often does not use it in a
way that maximizes end-user confidentiality. This specification proposes
changes to email software and deployments intended to increase the use
of TLS and record when that use occurs.
In brief, this memo now recommends that:
MUAs associate a confidentiality assurance level with each mail
account, and the default level requires use of TLS with certificate
validation for all TCP connections;TLS on a well-known port ("Implicit TLS") be supported for IMAP, POP,
and SMTP Submission for all electronic mail
user agents (MUAs), servers, and service providers;MUAs and mail protocol servers cooperate (via mechanisms defined in
this specification) to upgrade security/privacy feature use and
record/indicate that usage appropriately.Improved use of TLS with SMTP for message relaying is described in a
separate 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.
This draft is subject to change. Implementation of this proposal is not recommended at this time. Please discuss this proposal on the ietf-uta mailing list.
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 .This specification expresses syntax using the Augmented Backus-Naur
Form (ABNF) as described in , including the core rules in Appendix B and rules from .In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If a single "C:" or "S:" label applies to multiple
lines, then the line breaks between those lines are for editorial
clarity only and are not part of the actual protocol exchange.
A "mail account" refers to the network services an end user uses to
read, submit and manage email communications on the Internet. This
typically involves at least one mail access server (IMAP or POP) and at
least one SMTP submission server. An end users uses a mail user agent
(MUA) to access a mail account and most MUAs support one or more mail
accounts. This document uses the term "confidentiality assurance level"
to indicate the degree to which the network connections between an MUA
and a mail account have confidentiality protection from both passive and
active attackers on the network.
The configuration necessary for a mail account includes an email
address, connection information and authentication credentials for
network services. MUAs compliant with this specification MUST also
associate a confidentiality assurance level with each mail account. MUAs
MUST implement a high confidentiality assurance level as described in
the next section.
MUAs SHOULD continuously indicate to the user the confidentiality
assurance level of the account currently in use when reading, submitting
and managing mail (e.g., via a lock icon, background colors and
indications similar to those commonly used in web browsers for a similar
purpose) and SHOULD indicate the confidentiality assurance level for
each account whenever displaying a list of mail accounts. Note that the
displayed confidentiality assurance level could be higher than the level
set at account configuration but never lower. If multiple active
connections are associated with an account or view, the indication
should match the level provided by the least confidential connection.
Account configuration occurs when an MUA is first used to access a
particular service, when a user wishes to access or submit mail through
servers in addition to those specified or found during first use, or
when a user explicitly requests to change account configuration
parameters such as server names, user names, passwords, client
certificates, etc. Account configuration can be entirely manual
(entering server names explicitly) or partially automated via a
mechanism such as DNS SRV records . MUAs SHOULD
use the high confidentiality assurance level as the default for newly
configured accounts.
A mail account has a high confidentiality assurance when the following
conditions are met on all TCP server connections associated with an
account. This includes connections to POP, IMAP and SMTP submission
servers as well as any other associated protocols defined now or in the
future. Examples of protocols associated with a mail account include
managesieve and MTQP .
TCP connections MUST attempt to negotiate TLS via either Implicit TLS
or STARTTLS.MUAs MUST implement and PKIX .MUAs MAY implement DANE .User agents MUST abort a TLS session if the TLS negotiation fails or
the server's certificate or identity fails to verify. A user may
reconfigure the account to lower the expected level of confidentiality
if he/she chooses. Reduction of expected account confidentiality MUST
NOT be done on a click-through basis.
The end user is part of the system that protects the user's privacy and
security. As a result, it's critical not to present the end user with a
simple action that reduces their privacy in response to certificate
validation failure. An MUA which offers a user actions such as "connect
anyway", "trust certificate for future connections" or "lower
confidentiality assurance for this account" in response to certificate
validation failure is not providing a high confidentiality assurance as
defined in this section and thus does not comply with this document.
Examples of acceptable actions to offer would be "work offline", "try
again later", and "open service provider status web page".
MUAs MAY implement certificate pinning as part of account setup, but
MUST NOT offer this as an option in response to a failed certificate
validation for an existing account. Certificate pinning occurs when the
user agent saves a server certificate with the account settings and
trusts that certificate for subsequent connections to that server. An
MUA that allows certificate pinning MUST NOT allow a certificate pinned
for one account to validate connections for other accounts.
A pinned certificate is subject to a man-in-the-middle attack at account
setup time, and lacks a mechanism to revoke or securely refresh the
certificate. Therefore use of a pinned certificate does not provide a
high confidentiality assurance and an MUA MUST NOT indicate a high level
for an account or connection using a pinned certificate.
MUAs MAY implement a no confidentiality assurance level for accounts. At
this level, the MUA MUST attempt to negotiate TLS, but MAY ignore server
certificate validation failures. MUAs MAY support use of connections
without TLS, but if they do they SHOULD attempt TLS first if available
and MUST implement code to reconnect without TLS if TLS negotiation
fails for reasons other than server certificate validity.
Note that if the TLS certificate is not successfully validated as
described in or a version of SSL/TLS
prior to TLS 1.0 is used, the client MUST NOT present a high
confidentiality indication for the account or connection.
This specification is not intended to limit experimentation and
innovation with respect to user privacy. As a result more
confidentiality assurance levels are permitted. However, levels below
"no confidentiality assurance" described in the previous section are
discouraged and implementers are cautioned that end users may be
confused by too many confidentiality assurance levels.
Previous standards for use of email protocols with TLS used the STARTTLS
mechanism: , , and . With STARTTLS, the client establishes a clear text
application session and determines whether to issue a STARTTLS command
based on server capabilities and client configuration. If the client
issues a STARTTLS command, a TLS handshake follows that can upgrade the
connection. While this mechanism has been deployed, an alternate mechanism
where TLS is negotiated immediately at connection start on a separate
port (referred to in this document as "Implicit TLS") has been deployed more
successfully. To increase use of TLS, this specification recommends use
of implicit TLS by new POP, IMAP and SMTP Submission software.
When a TCP connection is established for the "pop3s" service (default
port 995), a TLS handshake begins immediately. Clients MUST implement
the certificate validation mechanism described in . Once the TLS session is
established, POP3 protocol messages are
exchanged as TLS application data for the remainder of the TCP
connection. After the server sends a +OK greeting, the server and
client MUST enter AUTHORIZATION state, even if client credentials were
supplied during the TLS handshake.
See for additional information on client
certificate authentication. See for port
registration information.
When a TCP connection is established for the "imaps" service (default
port 993), a TLS handshake begins immediately. Clients MUST implement
the certificate validation mechanism described in and SHOULD implement the certificate validation
mechanism described in . Once the TLS session is
established, IMAP protocol messages are
exchanged as TLS application data for the remainder of the TCP
connection. If client credentials were provided during the TLS
handshake that the server finds acceptable, the server MAY issue a
PREAUTH greeting in which case both the server and client enter
AUTHENTICATED state. If the server issues an OK greeting then both
server and client enter NOT AUTHENTICATED state.
See for additional information on client
certificate authentication. See for port
registration information.
When a TCP connection is established for the "submissions" service
(default port 465), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in . Once a TLS session is
established, message submission protocol data
is exchanged as TLS application data for the remainder of the TCP
connection. (Note: the "submissions" service name is defined in
section 10.3 of this document, and follows the usual convention that
the name of a service layered on top of Implicit TLS consists of the
name of the service as used without TLS, with an "s" appended.)
Note that the submissions port provides access to a Mail Submission
Agent (MSA) as defined in so requirements
and recommendations for MSAs in that document apply to the
submissions port, including the requirement to implement SMTP AUTH
.
See for additional information on client
certificate authentication. See for port
registration information.
When a client or server wishes to close the connection, it SHOULD
initiate the exchange of TLS close alerts before TCP connection
termination. The client MAY, after sending a TLS close alert, gracefully
close the TCP connection without waiting for a TLS response from the
server.
Once an improved email security or privacy mechanism is deployed and
ready for general use, it is desirable to continue using it for all
future email service. For example, TLS is widely deployed in email
software, but use of TLS is often not required. At the time this is
written, deployed mail user agents (MUAs)
usually make a determination if TLS is available when an account is
first configured and may require use of TLS with that account if and
only if it was initially available. If the service provider makes TLS
available after initial client configuration, many MUAs will not notice
the change.
Alternatively, a security feature may be purely opportunistic and thus
subject to downgrade attacks. For example, at the time this was written,
most TLS stacks that support TLS 1.2 will use an older TLS version if
the peer does not support TLS 1.2 and some do so without alerting the
client of the reduced security. Thus a variety of active attacks could
cause the loss of TLS 1.2 benefits. Only if client policy is upgraded to
require TLS 1.2 can the client prevent all downgrade attacks. However,
this sort of security policy upgrade will be ignored by most users
unless it is automated.
This section describes a mechanism, called "security latches", which is
designed to permit an MUA to recognize when a service provider has
committed to provide certain server security features, and that it's
safe for the client to change its configuration for that account to
require that such features be present in future sessions with that
server. When an MUA implements both confidentiality assurance levels and
security latches, then both the end-user and the service provider
independently have the ability to improve the end-user's privacy.
Note that security latches are a mechanism similar to HTTP Strict
Transport Security (HSTS) but are
extensible.
Each security latch is given a name known as an email security tag. An
email security tag is a short alphanumeric token that represents a
security facility that can be used by an IMAP, POP or SMTP Submission
session. When a server advertises a security tag it is making a
commitment to support that security facility indefinitely and
recommending that the client save that security tag with the account
configuration and require that security feature for future connections
to that server. When a security tag is saved by the client in this way,
it is then considered latched. For the "tls10" and/or "tls12" tags, the
client SHOULD refuse to connect to the server unless the appropriate
level of TLS is successfully negotiated. The client SHOULD NOT latch
these two tags until TLS has been successfully negotiated as described
in the tag definition. If the tags are advertised within an appropriate
TLS-protected connection, the client SHOULD latch these tags. Other
security tags are latched if they are advertised by the server, TLS is
active and the client successfully authenticates the server with the TLS
session. Once a security tag is latched, all subsequent connections to
that host require that security feature. For this confidentiality
protection to work as desired clients MUST NOT offer a
click-through-to-connect action when unable to achieve connection
security matching the latched security tags.
An identifier for a security tag has the following formal syntax:
This section describes an initial set of email security tags. The IANA Considerations defines a registry so that more tags can be defined in the future. The initial set of tags are defined in and include tls10, tls12, tls-cert and tls-dane-tlsa.
Servers supporting this extension MUST advertise a DEEP status. This
status includes a list of security-tags the server administrator has
explicitly configured as recommended for use by end-users (the list MAY
be empty), an optional https Uniform Resource Locator (URL) that the client can save and subsequently resolve for
the user in the event of a security connection problem, and the DEEP
status can be extended by future updates to this specification. DEEP
status has the following formal syntax:
The syntax for a Uniform Resource Identifier (URI) is defined in . Protocol extensions to advertise DEEP status are
defined in .
If the client successfully negotiates TLS and authenticates the server
(e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with channel
bindings ), then the client SHOULD record the
server's DEEP status information in the account configuration with the
server's hostname. Otherwise, the client SHOULD ignore the
server-provided DEEP status except for the "tls10" and "tls12" security
tags.
When a security tag latch has been set for connections from a client to
a server and the property identified by that tag is no longer available,
this results in a connection failure. An MUA SHOULD inform the user of a
potential threat to their confidentiality and offer to resolve a
previously-recorded DEEP status https URL if one is available. MUAs are
discouraged from offering a lightweight option to reset or ignore
latches as this defeats the benefit they provide to end users.
The ESMTPS transmission type provides trace
information that can indicate TLS was used when transferring mail.
However, TLS usage by itself is not a guarantee of confidentiality or
security. The TLS cipher suite provides additional information about the
level of security made available for a connection. This defines a new
SMTP "tls" Received header additional-registered-clause that is used to
record the TLS cipher suite that was negotiated for the connection. The
value included in this additional clause SHOULD be the registered cipher
suite name (e.g., TLS_DHE_RSA_WITH_AES_128_CBC_SHA) included in the TLS
cipher suite registry. In the event the implementation does not know the
name of the cipher suite (a situation that should be remedied promptly),
a four-digit hexadecimal cipher suite identifier MAY be used. The ABNF
for the field follows:
This memo defines optional mechanisms for use by MUAs to communicate
DEEP status to servers and for servers to advertise available latches.
One purpose of such mechanisms is to permit servers to determine which
and how many clients have latched security facilities, and thus, to
permit operators to be aware of potential impact to their users should
support for such facilities be changed. For IMAP, the existing ID
command is extended to provide this capability. For SMTP Submission, a
new CLIENT command is defined. No similar mechanism is defined for POP
in this version of the memo to keep POP simpler, but one may be added in
the future if deemed necessary.
In addition, for each of IMAP, POP, and SMTP, a new DEEP capability is
defined so the client can access the server's DEEP status.
When an IMAP server advertises the DEEP capability, that indicates the IMAP server implements IMAP4 ID with additional field values defined here. This is grouped with the ID command because that is the existing IMAP mechanism for clients to report data for server logging, and provides a way for the server to report the DEEP status.
From server to client, the argument to this ID field is the server DEEP status. Servers MUST provide this information in response to an ID command.From client to server, this is a space-separated
list of security tags the client has latched for this server. Servers
MAY record this information so administrators know the expected
latch-related security properties of the client and can thus act to
avoid security latch failures (e.g., by renewing server certificates on
time, etc).From client to server, a space-separated list
including one or more security tag the client has latched that the
client was unable to achieve. This allows clients to report errors to
the server prior to terminating the connection to the server in the
event an acceptable security level is unavailable.From client to server, this is a space-separated list of security tags the client supports that are not latched.Server-side IMAP proxies that accept TLS connections from clients and connect in-the-clear over a fully private secure network to the server SHOULD use this field to report the tls-cipher (syntax as defined in ) to the server.
IMAP clients SHOULD use the IMAP ID command to report latch failures and determine the server DEEP status. Clients MAY use the ID command to report other latch or security tag information. IMAP servers MUST implement the ID command at least to report DEEP status to clients.
This example shows a client that successfully negotiated TLS version
1.0 or later and verified the server's certificate as required by IMAP.
The client supports TLS 1.2. However, even if the client successfully
negotiated TLS 1.2, it will not latch that security tag automatically
because the server did not advertise that tag. If the client
successfully validated the server certificate, it will latch the
provided URL.This example shows a client that negotiated TLS, but was unable to verify the server's certificate. The latch-failure informs the server of this problem, at which point the client can disconnect. If the client had previously latched a URI for security problems from this server, it could offer to resolve that URI. However, the deep-status in this exchange is ignored due to the latch failure.This example shows the connection from an IMAP proxy to a back-end
server. The client connected to the proxy and sent the ID command
shown in example 1, and the proxy has added the "tls" item to the ID
command so the back-end server can log the cipher suite that was used
on the connection from the client.
POP servers supporting this specification MUST implement the POP3
extension mechanism . POP servers MUST
advertise the DEEP capability with an argument indicating the server's
DEEP status.
After verifying the TLS server certificate and issuing CAPA, the
client can latch any or all of the DEEP status. If the client connects
to this same server later and has a security failure, the client can
direct the user's browser to the previously-latched URI where the
service provider may provide advice to the end user.
SMTP Submission servers supporting this specification MUST implement the
DEEP SMTP extension. The name of this extension is DEEP. The EHLO
keyword value is DEEP and the deep-status ABNF is the syntax of the EHLO
keyword parameters. This does not add parameters to the MAIL FROM or
RCPT TO commands. This also adds a CLIENT command to SMTP which is used
to report client information to the server. The formal syntax for the
command follows:
The CLIENT command parameters listed here have the same meaning as the parameters used in the IMAP DEEP extension (). The server responds to the CLIENT command with a "250" if the command has correct syntax and a "501" if the command has incorrect syntax.
Although this document focuses on SMTP Submission, it is possible to use
security latches for SMTP transport as well. When MTA transport fails
due to a security latch, the MTA MUST use the SMTP enhanced status code
X.7.TBD (RFC Editor note: update this TBD). The SMTP notary response
for a security latch failure MUST include an
additional "SMTP-Security-Latch" recipient-specific header field that
includes a space-delimited list including one or more security latch
that failed. The ABNF for this new field follows:
This section updates by changing the
preference rules and adding a new SRV service label _submissions._tcp to
refer to Message Submission with implicit TLS.User-configurable MUAs SHOULD support use of for account setup. However, when using configuration information
obtained by this method, MUAs SHOULD default to a high confidentiality
assurance level, unless the user has explicitly requested reduced
confidentiality. This will have the effect of causing the MUA to ignore
advertised configurations that do not support TLS, even when those
advertised configurations have a higher priority than other advertised
configurations.When using configuration information, Mail
User Agents SHOULD NOT automatically establish new configurations that
do not require TLS for all servers, unless there are no advertised
configurations using TLS. If such a configuration is chosen, prior to
attempting to authenticate to the server or use the server for message
submission, the MUA SHOULD warn the user that traffic to that server
will not be encrypted and that it will therefore likely be intercepted
by unauthorized parties. The specific wording is to be determined by the
implementation, but it should adequately capture the sense of risk given
the widespread incidence of mass surveillance of email traffic.
When establishing a new configuration for connecting to an IMAP,
POP, or SMTP Submission server, an MUA SHOULD NOT blindly trust SRV
records 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.This section details requirements for implementations of electronic
mail protocol clients and servers. 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 Mail
Service Providers (MSPs) are distinct from requirements for protocol
implementations, and are listed in a separate section.These requirements apply to MUAs as well as POP, IMAP and SMTP
Submission servers.
All implementations MUST be configurable to support implicit TLS
using the TLS 1.2 protocol or later including
support for the mandatory-to-implement TLS 1.2 cipher suite
TLS_RSA_WITH_AES_128_CBC_SHA.IMAP implementations MUST support the IMAP4rev1 mandatory-to-implement
cipher suite TLS_RSA_WITH_RC4_128_MD5 for any connections made or
received via IMAP although this MAY be disabled by default.All implementations MUST be configurable to require TLS before
performing any operation other than capability discovery and STARTTLS.
MUAs and mail servers MAY implement client certificate authentication
on the implicit TLS port. Servers MUST NOT request a client
certificate during the TLS handshake unless the server is configured
to accept some client certificates as sufficient for authentication
and the server has the ability to determine a mail server
authorization identity matching such certificates. How to make this
determination is presently implementation specific. Clients MUST NOT
provide a client certificate during the TLS handshake unless the
server requests one and the client has determined the certificate can
be safely used with that specific server, OR the client has been
explicitly configured by the user to use that particular certificate
with that server. How to make this determination is presently
implementation specific. If the server accepts the client's
certificate as sufficient for authorization, it MUST enable the SASL
EXTERNAL mechanism. An IMAPS server MAY issue
a PREAUTH greeting instead of enabling SASL EXTERNAL. A client
supporting client certificate authentication with implicit TLS MUST
implement the SASL EXTERNAL mechanism using
the appropriate authentication command (AUTH for POP3 , AUTH for SMTP Submission ,
AUTHENTICATE for IMAP ).
These requirements apply to servers that implement POP, IMAP or
SMTP Submission.
Servers MUST implement the DEEP extension described in IMAP and SMTP submission servers SHOULD implement and be configurable
to support STARTTLS. This enables discovery of new TLS availability, and
can increase usage of TLS by legacy clients.Servers MUST NOT advertise STARTTLS if it is unlikely to succeed
based on server configuration (e.g., there is no server certificate
installed).SMTP message submission servers that have negotiated TLS SHOULD add
a Received header field to the message including the tls clause
described in .Servers MUST be configurable to include the TLS cipher information
in any connection or user logging or auditing facility they
provide.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
(e.g., port 25) for mail submission.
User agents SHOULD indicate to users at configuration time, the
expected level of confidentiality based on appropriate security inputs
such as which security latches are pre-set, the number of trust anchors,
certificate validity, use of an extended validation certificate, TLS
version supported, and TLS cipher suites supported by both server and
client. This indication SHOULD also be present when editing or viewing
account configuration.MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes
available for a protocol and set the tls10 latch if the server
advertises the tls10 security tag after a successful TLS
negotiation.Whenever requested to establish any configuration that does not
require both TLS and server certificate verification to talk to a
server or account, an MUA SHOULD warn its user that his or her mail
traffic (including password, if applicable) will be exposed to
attackers, and give the user an opportunity to abort the connection
prior to transmission of any such password or traffic.MUAs SHOULD implement the "tls12" security latch (the TLS library has
to provide an API that controls permissible TLS versions and
communicates the negotiated TLS protocol version to the application for
this to be possible).See for additional requirements.MUAs which are not configurable to use user-specified servers MUST
implement 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.MUAs using protocols other than IMAP, POP, and Submission to
communicate with mail servers, MUST implement TLS or other similarly
robust encryption mechanism in conjunction with those protocols.There are multiple ways to connect an Anti-Virus and/or Anti-Spam
(AVAS) service to a mail server. Some mechanisms, such as the de-facto
milter protocol do not impact DEEP. However, some services use an SMTP
relay proxy that intercepts mail at the application layer to perform a
scan and proxy to the real MTA. Deploying AVAS services in this way can
cause many problems including direct
interference with DEEP and confidentiality or security reduction. An
AVAS product or service is considered DEEP compliant if all IMAP, POP
and SMTP-related software it includes is DEEP compliant and it
advertises and supports all security latches that the actual MTA
advertises.This section details requirements for providers of IMAP, POP, and/or
SMTP submission services, for providers who claim to conform to this
specification.Mail Service Providers MUST use server implementations that
conform to this specification.This document updates the advice in by
making Implicit TLS on port 465 the preferred submission port.Mail Service Providers that accept mail submissions from
end-users using the Internet Protocol MUST provide one or more SMTP
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 on port 465 and SHOULD support
STARTTLS if port 587 is used.MSPs MAY also support submission of messages via one or
more designated SMTP servers to facilitate compatibility with
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 mail submission servers to accept mail in
cleartext or without authentication. For other reasons, use of
separate SMTP submission servers has been best practice for many
years.MSPs MUST maintain valid server certificates for all servers.
Those server certificates SHOULD present DNS-IDs and SRV-IDs
conforming to and which will be
recognized by MUAs meeting the requirements of that specification.
In addition, those server certificates MAY provide other DNS-IDs,
SRV-IDs, or CN-IDs needed for compatibility with existing
MUAs.If a protocol server provides service for more than one
mail domain, it MAY use a separate IP address for each domain
and/or a server certificate that advertises multiple
domains. This will generally be necessary unless and until it
is acceptable to impose the constraint that the server and all
clients support the Server Name Indication extension to
TLS .This section discusses not only the DNS records that are
recommended, but also implications of DNS records for server
configuration and TLS server certificates.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.MSPs SHOULD advertise SRV records to aid MUAs in
determination of proper configuration of servers, per the
instructions in .MSPs SHOULD advertise servers that support Implicit TLS
in preference to those which support cleartext and/or
STARTTLS operation.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.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.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, 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 and a
significant support burden for the MSP.MSPs SHOULD advertise a DEEP status that includes tls10, tls-cert
and an HTTPS URL that can be used to inform clients of service
outages or problems impacting client confidentiality. Note that
advertising tls-cert is a commitment to maintain and renew server
certificates.New servers and services SHOULD be configured to require TLS
unless it's necessary to support legacy clients or existing client
configurations.When an MSP changes the Internet Facing Servers providing mail access and mail submission services, including SMTP-based spam/virus filters, it is generally necessary to support the same and/or a newer version of TLS and the same security tags that were previously advertised.IANA shall create (has created) the registry "Email Security Tags". This registry is a single table and will use an expert review process . Each registration will contain the following fields:
The name of the security tag. This follows the security-tag ABNF.This describes the meaning of the security tag and the conditions under which the tag is latched.One of COMMON, LIMITED USE or OBSOLETE.Optional reference to specification.The identify of the submitter or submitters.The identity of the change controller
for the registration. This will be "IESG" in case of registrations in
IETF-produced documents.
The expert reviewer will verify the tag name follows the ABNF, and that
the description field is clear, unambiguous, does not overlap existing
deployed technology, does not create security or privacy problems and
appropriately considers interoperability issues. Email security tags
intended for LIMITED USE have a lower review bar (interoperability and
overlap issues are less of a concern). The reviewer may approve a
registration, reject for a stated reason or recommend the proposal have
standards track review due to importance or difficult subtleties.
Standards-track registrations may be updated if the relevant standards
are updated as a consequence of that action. Non-standards-track entries
may be updated by the listed change controller. The entry's name and
submitter may not be changed. In exceptional cases, any aspect of any
registered entity may be updated at the direction of the IESG (for
example, to correct a conflict).
This document defines four initial security tags for the security tag registry as follows:
tls10This indicates TLS version 1.0 or later was negotiated successfully including
negotiation of a strong encryption layer with a symmetric key of at
least 128 bits. This tag does not indicate the server certificate was
valid. This tag is latched if the client sees this tag in the advertised
server DEEP status provided after successfully negotiating TLS version
1.0 or later.COMMONRFC XXXX (this document once published)Authors of this documentIESGtls12This indicates TLS version 1.2 or later was negotiated successfully including
negotiation of a strong encryption layer with a symmetric key of at
least 128 bits. This tag does not indicate the server certificate was
valid. This tag is latched if the client sees this tag in the advertised
server DEEP status provided after successfully negotiating TLS version
1.2 or later.COMMONRFC XXXX (this document once published)Authors of this documentIESGtls-certThis tag indicates that TLS was successfully
negotiated and the server certificate was successfully verified by the
client using PKIX and the server certificate
identity was verified using the algorithm appropriate for the protocol
(see ). This tag is latched if the client
sees this tag in the advertised server DEEP status after successfully
negotiating TLS and verifying the certificate and server identity.COMMONRFC XXXX (this document once published)Authors of this documentIESGtls-dane-tlsaThis tag indicates that TLS was successfully
negotiated and the server certificate was successfully verified by the
client using the procedures described in and
the server certificate identity was verified using the algorithm
appropriate for the protocol (see ). This
tag is latched if the client sees this tag in the advertised server DEEP
status after successfully negotiating TLS and verifying the certificate
and server identity.COMMONRFC XXXX (this document once published)Authors of this documentIESG
IANA is asked to update the registration of the TCP well-known port 995 using the following template ():
IANA is asked to update the registration of the TCP well-known port 993 using the following template ():
IANA is asked to assign an alternate usage of port 465 in addition to the current assignment using the following template ():
This is a one time procedural exception to the rules in RFC 6335. This
requires explicit IESG approval and does not set a precedent.
Historically, port 465 was briefly registered as the "smtps" port. This
registration made no sense as the SMTP transport MX infrastructure has
no way to specify a port so port 25 is always used. As a result, the
registration was revoked and was subsequently reassigned to a different
service. In hindsight, the "smtps" registration should have been renamed
or reserved rather than revoked. Unfortunately, some widely deployed
mail software interpreted "smtps" as "submissions" and used that port for email submission by default
when an end-user requests security during account setup. If a new port
is assigned for the submissions service, email software will either
continue with unregistered use of port 465 (leaving the port registry
inaccurate relative to de-facto practice and wasting a well-known port),
or confusion between the de-facto and registered ports will cause
harmful interoperability problems that will deter use of TLS for message
submission. The authors believe both of these outcomes are less
desirable than a wart in the registry documenting real-world usage of
a port for two purposes. Although STARTTLS-on-port-587 has deployed, it
has not replaced deployed use of implicit TLS submission on port 465.
This document adds the DEEP capability to the IMAP capabilities registry. This is described in .This document adds the DEEP capability to the POP3 capabilities registry.
DEEPdeep-statusnonenoneboth / may change after STLSN/AThis documentSee .This document adds the DEEP EHLO Keyword to the SMTP Service Extension registry. This is described in .This document adds the following entry to the "SMTP Enhanced Status Codes" registry created by .
X.7.TBD (IANA, please assign the next available number)Message Transport Failed due to missing required security.450, 454, 550, 554This code indicates an SMTP server was unable
to forward a message to the next host necessary for delivery because it
required a higher level of transport security or confidentiality than
was available. The temporary form of this error is preferred in case the
problem is caused by a temporary administrative error such as an expired
server certificate.This documentC. NewmanIESG
This document adds the following entry to the "Additional-registered-clauses" sub-registry of the "MAIL Parameters" registry, created by :
tlsIndicates the TLS cipher suite used for a transport connection.See tls-cipher ABNF This document.
This entire document is about security considerations. In general, this
is targeted to improve mail privacy and to mitigate threats external to
the email system such as network-level snooping or interception; this is
not intended to mitigate active attackers who have compromised service
provider systems.
It could be argued that sharing the name and version of the client
software with the server has privacy implications. Although providing
this information is not required, it is encouraged so that mail service
providers can more effectively inform end-users running old clients that
they need to upgrade to protect their security, or know which clients to
use in a test deployment prior to upgrading a server to have higher
security requirements.
This section is not normative.
The first version of this was written independently from
draft-moore-email-tls-00.txt; subsequent versions merge ideas from both
drafts.
One author of this document was also the author of RFC 2595 that
became the standard for TLS usage with POP and IMAP, and the other
author was perhaps the first to propose that idea. In hindsight both
authors now believe that that approach was a mistake. At this point
the authors believe that while anything that makes it easier to deploy
TLS is good, the desirable end state is that these protocols always
use TLS, leaving no need for a separate port for cleartext operation
except to support legacy clients while they continue to be used. The
separate port model for TLS is inherently simpler to implement, debug
and deploy. It also enables a "generic TLS load-balancer" that accepts
secure client connections for arbitrary foo-over-TLS protocols and
forwards them to a server that may or may not support TLS. Such
load-balancers cause many problems because they violate the end-to-end
principle and the server loses the ability to log security-relevant
information about the client unless the protocol is designed to
forward that information (as this specification does for the cipher
suite). However, they can result in TLS deployment where it would not
otherwise happen which is a sufficiently important goal that it
overrides the problems.
Although STARTTLS appears only slightly more complex than separate-port
TLS, we again learned the lesson that complexity is the enemy of
security in the form of the STARTTLS command injection vulnerability
(CERT vulnerability ID #555316). Although there's nothing inherently wrong with STARTTLS, the fact it resulted in a common implementation error (made independently by multiple implementers) suggests it is a less secure architecture than Implicit TLS.
Section 7 of RFC 2595 critiques the separate-port approach to TLS. The
first bullet was a correct critique. There are proposals in the http
community to address that, and use of SRV records as described in RFC
6186 resolves that critique for email. The second bullet is correct as
well, but not very important because useful deployment of security
layers other than TLS in email is small enough to be effectively
irrelevant. The third bullet is incorrect because it misses the
desirable option of "use and latch-on TLS if available". The fourth
bullet may be correct, but is not a problem yet with current port
consumption rates. The fundamental error was prioritizing a perceived
better design based on a mostly valid critique over real-world
deployability. But getting security and confidentiality facilities
actually deployed is so important it should trump design purity
considerations.
There are many open issues with this document. Here is an attempt to enumerate some of them:
Port 465 is presently used for two purposes: for submissions by a large
number of clients and service providers and for the "urd" protocol by
one vendor. Actually documenting this current state is controversial as
discussed in the IANA considerations section. However, there is no good
alternative. Registering a new port for submissions when port 465 is
widely used for that purpose already will just create interoperability
problems. Registering a port that's only used if advertised by an SRV
record (RFC 6186) would not create interoperability problems but would
require all client and server deployments and software to change
significantly which is contrary to the goal of promoting more TLS use.
Encouraging use of STARTTLS on port 587 would not create
interoperability problems, but is unlikely to have impact on current
undocumented use of port 465 and makes the guidance in this document
less consistent.
This document should reference draft-ietf-uta-tls-bcp and possibly other
guidance documents. Suggested text on where/how to reference this and
possibly other TLS guidance (e.g., must staple). would be welcome.
One author believes that the security latch model is complementary with
draft-ietf-dane-smtp-with-dane-02 but hasn't thought about the issues in
depth. We welcome feedback on this point.
The two authors of this document and the author of draft-melnikov-email-tls-certs are willing to merge these two documents. However, it is undesirable to delay publication of either document so this will be done only if the latter document is not yet through IESG processing when this document is ready for the IESG.
It might make sense to split this in two or more documents if it's
getting too long to evaluate in one IETF last call. In particular, it
might make sense to put implementation requirements and service provider
requirements in separate documents. The authors prefer to edit one
document for now and defer discussion of splitting the document until
all technical issues are resolved.
The use of SRV records for account setup or
refresh is presently not secure from DNS active attacks unless DNSSEC
is used. As this document is now focusing on MUA security/privacy,
discussing how to do SRV record account setup or account refresh
securely, probably using DANE, would be in scope for this document. It
has been suggested that we add this.
This document does not cover use of TLS with SMTP relay.
Changes since draft-newman-email-deep-02:
Changed "privacy assurance" to "confidentiality assurance"Changed "low privacy assurance" to "no confidentiality assurance"Attempt to improve definition of confidentiality assurance level.Add SHOULD indicate when MUA is showing list of mail accounts.Add SHOULD NOT latch tls10, tls12 tags until TLS negotiated.Removed sentence about deleting and re-creating the account in latch failure section.Remove use of word "fallback" with respect to TLS version negotiation.Added bullet about changes to Internet facing servers to MSP section.minor wording improvements based on feedbackChanges since -01:
Updated abstract, introduction and document structure to focus more on mail user agent privacy assurance.Added email account privacy section, also moving section on account
setup using SRV records to that section.Finished writing IANA considerations sectionRemove provisional concept and instead have server explicitly list
security tags clients should latch.Added note that rules for the submissions port follow the same
rules as those for the submit port.Reference and update advice in .Fixed typo in Client Certificate Authentication section.Removed tls-pfs security latch and all mention of perfect forward
secrecy as it was controversial.Added reference to HSTS.Changes since -00:
Rewrote introduction to merge ideas from draft-moore-email-tls-00.Added Implicit TLS section, Account configuration section and IANA port registration updates based on draft-moore-email-tls-00.Add protocol details necessary to standardize implicit TLS for POP/IMAP/submission, using ideas from draft-melnikov-pop3-over-tls.Reduce initial set of security tags based on feedback.Add deep status concept to allow a window for software updates to be backed out before latches make that problematic, as well as to provide service providers with a mechanism they can use to assist customers in the event of a privacy failure.Add DNS SRV section from draft-moore-email-tls-00.Write most of the missing IANA considerations section.Rewrite most of implementation requirements section based more on
draft-moore-email-tls-00. Remove new cipher requirements for now
because those may be dealt with elsewhere.Many thanks to Ned Freed for discussion of the initial latch concepts in this document. Thanks to Alexey Melnikov for draft-melnikov-pop3-over-tls-02, which was the basis of the POP3 implicit TLS text. Thanks to Dan Newman and Alexey Melnikov for review feedback. Thanks to Paul Hoffman for interesting feedback in initial conversations about this idea.