draft-ietf-uta-email-deep-05.txt   draft-ietf-uta-email-deep-06.txt 
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Network Heretics Internet-Draft Network Heretics
Updates: 1939, 2595, 3464, 3501, 5068, C. Newman Updates: 1939, 2595, 3464, 3501, 5068, C. Newman
6186, 6409 (if approved) Oracle 6186, 6409 (if approved) Oracle
Intended status: Standards Track July 9, 2016 Intended status: Standards Track March 13, 2017
Expires: January 10, 2017 Expires: September 14, 2017
Mail User Agent Strict Transport Security (MUA-STS) Mail User Agent Strict Transport Security (MUA-STS)
draft-ietf-uta-email-deep-05.txt draft-ietf-uta-email-deep-06
Abstract Abstract
This specification defines a set of requirements and facilities This specification defines a set of requirements and facilities
designed to improve email confidentiality between a mail user agent designed to improve email confidentiality between a mail user agent
(MUA) and a mail submission or mail access server. This provides (MUA) and a mail submission or mail access server. This provides
mechanisms intended to increase use of already deployed Transport mechanisms intended to increase use of already deployed Transport
Layer Security (TLS) technology and provides a model for a mail user Layer Security (TLS) technology and provides a model for a mail user
agent's confidentiality assurance. This enables mail service agent's confidentiality assurance. This enables mail service
providers to advertise strict transport security (STS) policies that providers to advertise strict transport security (STS) policies that
request MUAs increase confidentiality assurance. request MUAs increase confidentiality assurance.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology Used in This Document . . . . . . 4 2. Conventions and Terminology Used in This Document . . . . . . 4
3. Mail Account Confidentiality Assurance Level . . . . . . . . . 5 3. Mail Account Confidentiality Assurance Level . . . . . . . . 4
3.1. High Confidentiality Assurance . . . . . . . . . . . . . . 6 3.1. Confidentiality Assurance Level 1 . . . . . . . . . . . . 6
3.2. No Confidentiality Assurance . . . . . . . . . . . . . . . 6 3.2. Confidentiality Assurance Level 0 . . . . . . . . . . . . 7
3.3. Other Confidentiality Assurance Levels . . . . . . . . . . 7 3.3. Other Confidentiality Assurance Levels . . . . . . . . . 7
4. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Implicit TLS for POP . . . . . . . . . . . . . . . . . . . 7 4.1. Implicit TLS for POP . . . . . . . . . . . . . . . . . . 8
4.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 7 4.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 8
4.3. Implicit TLS for SMTP Submission . . . . . . . . . . . . . 8 4.3. Implicit TLS for SMTP Submission . . . . . . . . . . . . 8
4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP . . 9 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP . 9
5. Email Security Upgrading Using Security Directives . . . . . . 9 5. Email Security Upgrading Using Security Directives . . . . . 9
6. Server Strict Transport Security Policy . . . . . . . . . . . 10 6. Server Strict Transport Security Policy . . . . . . . . . . . 11
7. Client Storage of Email Security Directives . . . . . . . . . 10 7. Client Storage of Email Security Directives . . . . . . . . . 11
7.1. Security Directive Upgrade Example . . . . . . . . . . . . 11 7.1. Security Directive Upgrade Example . . . . . . . . . . . 12
7.2. Security Policy Failures . . . . . . . . . . . . . . . . . 11 7.2. Security Policy Failures . . . . . . . . . . . . . . . . 12
8. Recording TLS Cipher Suite in Received Header . . . . . . . . 12 8. Recording TLS Cipher Suite in Received Header . . . . . . . . 12
9. Extensions for STS Policy and Reporting . . . . . . . . . . . 12 9. Extensions for STS Policy and Reporting . . . . . . . . . . . 13
9.1. IMAP STS Extension . . . . . . . . . . . . . . . . . . . . 12 9.1. IMAP STS Extension . . . . . . . . . . . . . . . . . . . 13
9.2. POP DEEP Extension . . . . . . . . . . . . . . . . . . . . 15 9.2. POP DEEP Extension . . . . . . . . . . . . . . . . . . . 15
9.3. SMTP MSTS Extension . . . . . . . . . . . . . . . . . . . 15 9.3. SMTP MSTS Extension . . . . . . . . . . . . . . . . . . . 16
10. Account Setup Considerations . . . . . . . . . . . . . . . . . 17 10. Account Setup Considerations . . . . . . . . . . . . . . . . 18
10.1. Use of SRV records in Establishing Configuration . . . . . 17 10.1. Use of SRV records in Establishing Configuration . . . . 18
10.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 18 10.2. Certificate Pinning . . . . . . . . . . . . . . . . . . 19
11. Implementation Requirements . . . . . . . . . . . . . . . . . 18 11. Implementation Requirements . . . . . . . . . . . . . . . . . 19
11.1. All Implementations (Client and Server) . . . . . . . . . 18 11.1. All Implementations (Client and Server) . . . . . . . . 19
11.1.1. Client Certificate Authentication . . . . . . . . . . 19 11.1.1. Client Certificate Authentication . . . . . . . . . 20
11.2. Mail Server Implementation Requirements . . . . . . . . . 19 11.2. Mail Server Implementation Requirements . . . . . . . . 21
11.3. Mail User Agent Implementation Requirements . . . . . . . 20 11.3. Mail User Agent Implementation Requirements . . . . . . 21
11.4. Non-configurable MUAs and nonstandard access protocols . . 21 11.4. Non-configurable MUAs and nonstandard access protocols . 22
11.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and 11.5. Compliance for Anti-Virus/Anti-Spam Software and
Services . . . . . . . . . . . . . . . . . . . . . . . . . 21 Services . . . . . . . . . . . . . . . . . . . . . . . . 22
12. Mail Service Provider Requirements . . . . . . . . . . . . . . 21 12. Mail Service Provider Requirements . . . . . . . . . . . . . 23
12.1. Server Requirements . . . . . . . . . . . . . . . . . . . 22 12.1. Server Requirements . . . . . . . . . . . . . . . . . . 23
12.2. MSPs MUST provide Submission Servers . . . . . . . . . . . 22 12.2. MSPs MUST provide Submission Servers . . . . . . . . . . 23
12.3. TLS Server Certificate Requirements . . . . . . . . . . . 22 12.3. TLS Server Certificate Requirements . . . . . . . . . . 23
12.4. Recommended DNS records for mail protocol servers . . . . 22 12.4. Recommended DNS records for mail protocol servers . . . 24
12.4.1. MX records . . . . . . . . . . . . . . . . . . . . . 23 12.4.1. MX records . . . . . . . . . . . . . . . . . . . . . 24
12.4.2. SRV records . . . . . . . . . . . . . . . . . . . . . 23 12.4.2. SRV records . . . . . . . . . . . . . . . . . . . . 24
12.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 23 12.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 24
12.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . 23 12.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . 24
12.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . . 23 12.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . 24
12.6. Advertisement of DEEP status . . . . . . . . . . . . . . . 23 12.6. Advertisement of STS policies . . . . . . . . . . . . . 25
12.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . . 24 12.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . 25
12.8. Changes to Internet Facing Servers . . . . . . . . . . . . 24 12.8. Changes to Internet Facing Servers . . . . . . . . . . . 25
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
13.1. Security Directive Registry . . . . . . . . . . . . . . . 24 13.1. Security Directive Registry . . . . . . . . . . . . . . 25
13.2. Initial Set of Security Directives . . . . . . . . . . . . 25 13.2. Initial Set of Security Directives . . . . . . . . . . . 26
13.3. POP3S Port Registration Update . . . . . . . . . . . . . . 27 13.3. POP3S Port Registration Update . . . . . . . . . . . . . 29
13.4. IMAPS Port Registration Update . . . . . . . . . . . . . . 28 13.4. IMAPS Port Registration Update . . . . . . . . . . . . . 29
13.5. Submissions Port Registration . . . . . . . . . . . . . . 28 13.5. Submissions Port Registration . . . . . . . . . . . . . 29
13.6. STS IMAP Capability . . . . . . . . . . . . . . . . . . . 29 13.6. STS IMAP Capability . . . . . . . . . . . . . . . . . . 30
13.7. STS POP3 Capability . . . . . . . . . . . . . . . . . . . 29 13.7. STS POP3 Capability . . . . . . . . . . . . . . . . . . 30
13.8. MSTS SMTP EHLO Keyword . . . . . . . . . . . . . . . . . . 30 13.8. MSTS SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 30
13.9. MAIL Parameters Additional-registered-clauses 13.9. MAIL Parameters Additional-registered-clauses Sub-
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 30 Registry . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Security Considerations . . . . . . . . . . . . . . . . . . . 30 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . . 30 15.1. Normative References . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Design Considerations . . . . . . . . . . . . . . . . 34 Appendix A. Design Considerations . . . . . . . . . . . . . . . 35
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
Software that provides email service via Internet Message Access Software that provides email service via Internet Message Access
Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] and/
and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually
usually has Transport Layer Security (TLS) [RFC5246] support but has Transport Layer Security (TLS) [RFC5246] support but often does
often does not use it in a way that maximizes end-user not use it in a way that maximizes end-user confidentiality. This
confidentiality. This specification proposes changes to email specification proposes changes to email software and deployments
software and deployments intended to increase the use of TLS and intended to increase the use of TLS and record when that use occurs.
record when that use occurs. This adapts the strict transport This adapts the strict transport security (STS) model described in
security (STS) model described in [RFC6797] to cover mail user agents [RFC6797] to cover mail user agents (MUAs).
(MUAs).
In brief, this memo now recommends that: In brief, this memo now recommends that:
o MUAs associate a confidentiality assurance level with each mail o MUAs associate a minimum confidentiality assurance level with each
account, and the default level requires use of TLS with mail account, and disconnections associated with that account that
certificate validation for all TCP connections; do not provide the minimum confidentiality assurance level
associated with that account.
o By default, MUAs assign a minimum confidentiality assurance level
that requires use of TLS with certificate validation for all TCP
connections;
o TLS on a well-known port ("Implicit TLS") be supported for IMAP, o TLS on a well-known port ("Implicit TLS") be supported for IMAP,
POP, and SMTP Submission [RFC6409] for all electronic mail user POP, and SMTP Submission [RFC6409] for all electronic mail user
agents (MUAs), servers, and service providers; agents (MUAs), servers, and service providers;
o MUAs and mail protocol servers cooperate (via mechanisms defined o MUAs and mail protocol servers cooperate (via mechanisms defined
in this specification) to upgrade security feature use and record/ in this specification) to upgrade security feature use and record/
indicate that usage appropriately. The security upgrade model is indicate that usage appropriately. The security upgrade model is
aligned with the HTTP STS specification [RFC6797]. aligned with the HTTP STS specification [RFC6797].
skipping to change at page 5, line 20 skipping to change at page 4, line 48
server respectively. If a single "C:" or "S:" label applies to server respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol editorial clarity only and are not part of the actual protocol
exchange. exchange.
3. Mail Account Confidentiality Assurance Level 3. Mail Account Confidentiality Assurance Level
A "mail account" refers to the network services an end user uses to A "mail account" refers to the network services an end user uses to
read, submit and manage email communications on the Internet. This read, submit and manage email communications on the Internet. This
typically involves at least one mail access server (IMAP or POP) and 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 at least one SMTP submission server. An end user uses a mail user
agent (MUA) to access a mail account and most MUAs support one or agent (MUA) to access a mail account. (Most MUAs support the ability
more mail accounts. This document uses the term "confidentiality to access multiple mail accounts.) This document uses the term
assurance level" to indicate the degree to which the network "confidentiality assurance level" to indicate the degree to which the
connections between an MUA and a mail account have confidentiality network connections between an MUA and a mail account have
protection from both passive and active attackers on the network. confidentiality protection from both passive and active attackers on
the network.
The configuration necessary for a mail account includes an email The configuration necessary for a mail account includes an email
address, connection information and authentication credentials for address, connection information, and authentication credentials for
network services. MUAs compliant with this specification MUST also network services. MUAs compliant with this specification MUST also
associate a confidentiality assurance level with each mail account. associate a minimum confidentiality assurance level with each mail
MUAs MUST implement a high confidentiality assurance level as account. If during a session with a network service, the
described in the next section. requirements for the minimum confidentiality assurance level
associated with that mail account are not met, the MUA MUST NOT
continue the session with the network service. MUAs MUST support at
least the ability to detect whether a session with a network service
implements confidentiality assurance level 1 as described in the next
section. Note that the minimum confidentiality assurance level
associated with an account applies to all protocol interactions and
all servers associated with the account.
MUAs SHOULD continuously indicate to the user the confidentiality MUAs SHOULD continuously indicate to the user the current
assurance level of the account currently in use when reading, confidentiality assurance level of any account currently in use when
submitting and managing mail (e.g., via a lock icon, background reading, submitting and managing mail (e.g., via a lock icon,
colors and indications similar to those commonly used in web browsers background colors, or other indications similar to those commonly
for a similar purpose) and SHOULD indicate the confidentiality used in web browsers for a similar purpose) and SHOULD indicate the
assurance level for each account whenever displaying a list of mail minimum confidentiality assurance level for each account whenever
accounts. Note that the displayed confidentiality assurance level displaying a list of mail accounts. Note that the displayed
could be higher than the level set at account configuration but never confidentiality assurance level for a current session could be higher
lower. If multiple active connections are associated with an account than the minimum confidentiality assurance level set at account
or view, the indication should match the level provided by the least configuration, but never lower. If multiple active connections are
confidential connection. associated with an account or view, the indication of the current
confidentiality assurance level associated with the account should
reflect the level provided by the least confidential connection. It
is therefore possible that at any given instant some services
associated with a mail account meet the minimum confidentiality
assurance level associated with the account, and other services do
not. An MUA MAY continue to interact with those services for which
the minimum confidentiality assurance level is met, while refusing to
interact with those services for which the minimum confidentiality
assurance level is not met. For example, if the IMAP service
associated with a mail account meets the minimum confidentiality
assurance level, but the Mail Submission service associated with that
account does not, the MUA MAY continue to permit reading mail from
that account but MUST NOT send mail until it can do so using a
Submission service that meets the minimum confidentiality assurance
level for that account.
Account configuration occurs when an MUA is first used to access a Account configuration occurs when an MUA is first used to access a
particular service, when a user wishes to access or submit mail particular service, when a user wishes to access or submit mail
through servers in addition to those specified or found during first through servers in addition to those specified or found during first
use, or when a user explicitly requests to change account use, or when a user explicitly requests to change account
configuration parameters such as server names, user names, passwords, configuration parameters such as server names, user names, passwords,
client certificates, etc. Account configuration can be entirely client certificates, etc. Account configuration can be entirely
manual (entering server names explicitly) or partially automated via manual (entering server names explicitly) or partially automated via
a mechanism such as DNS SRV records [RFC6186]. MUAs SHOULD use the a mechanism such as DNS SRV records [RFC6186]. MUAs SHOULD require a
high confidentiality assurance level as the default for newly minimum confidentiality assurance level of 1 as the default for newly
configured accounts. configured accounts.
3.1. High Confidentiality Assurance This document defines two initial confidentiality assurance levels, 1
and 0. It is expected that other levels may be defined in the
future, as needed to thwart increasingly sophisticated and/or
pervasive attacks.
A mail account has a high confidentiality assurance when the 3.1. Confidentiality Assurance Level 1
A mail account has a confidentiality assurance level of 1 when the
following conditions are met on all TCP server connections associated following conditions are met on all TCP server connections associated
with an account. This includes connections to POP, IMAP and SMTP with an account. This includes connections to POP, IMAP and SMTP
submission servers as well as any other associated protocols defined submission servers as well as any other associated protocols defined
now or in the future. Examples of protocols associated with a mail now or in the future. Examples of protocols associated with a mail
account include managesieve [RFC5804] and MTQP [RFC3887]. account include managesieve [RFC5804] and MTQP [RFC3887].
o TCP connections MUST attempt to negotiate TLS via either Implicit o TCP connections MUST successfully negotiate TLS via either
TLS Section 4 or STARTTLS. Implicit TLS Section 4 or STARTTLS.
o For protocols using TCP, both client and server must support, and
negotiate, a TLS version of 1.1 or greater.
o MUAs MUST implement [RFC7817] and PKIX [RFC5280]. o MUAs MUST implement [RFC7817] and PKIX [RFC5280].
o MUAs MAY implement DANE [RFC6698]. o MUAs MAY implement DANE [RFC6698] as an alternate means of
verifying TLS server certificates. For confidentiality assurance
level 1, a certificate may be considered valid if it can be
validated using either DANE or PKIX.
o User agents MUST abort a TLS session if the TLS negotiation fails o User agents MUST abort a TLS session if the TLS negotiation fails
or the server's certificate or identity fails to verify. A user or the server's certificate or identity fails to verify. A user
may reconfigure the account to lower the expected level of may reconfigure the account to lower the expected level of
confidentiality if he/she chooses. Reduction of expected account confidentiality if he/she chooses. Reduction of expected account
confidentiality MUST NOT be done on a click-through basis. confidentiality MUST NOT be done on a click-through basis.
The end user is part of the system that protects the user's The end user is part of the system that protects the user's
confidentiality and security. As a result, it's critical not to confidentiality and security. As a result, it's critical not to
present the end user with a simple action that reduces their present the end user with a simple action that reduces their
confidentiality in response to certificate validation failure. An confidentiality in response to certificate validation failure. An
MUA which offers a user actions such as "connect anyway", "trust MUA which offers a user actions such as "connect anyway", "trust
certificate for future connections" or "lower confidentiality certificate for future connections" or "lower confidentiality
assurance for this account" in response to certificate validation assurance for this account" in response to certificate validation
failure is not providing a high confidentiality assurance as defined failure is not implementing a minimum confidentiality assurance of 1
in this section and thus does not comply with this document. as defined in this section and thus does not comply with this
Examples of acceptable actions to offer would be "work offline", "try document. Examples of acceptable actions to offer would be "work
again later", and "open service provider status web page". offline", "try again later", and "open service provider status web
page".
3.2. No Confidentiality Assurance 3.2. Confidentiality Assurance Level 0
MUAs MAY implement a no confidentiality assurance level for accounts. MUAs MAY support the ability to configure accounts with a minimum
At this level, the MUA MUST attempt to negotiate TLS, but MAY ignore confidentiality assurance level of 0. At this level, the MUA MUST
server certificate validation failures. MUAs MAY support use of attempt to negotiate TLS, but MAY ignore server certificate
connections without TLS, but if they do they SHOULD attempt TLS first validation failures. MUAs MAY support use of connections without
if available and MUST implement code to reconnect without TLS if TLS TLS, or using TLS versions prior to TLS 1.1, for accounts with a
negotiation fails for reasons other than server certificate validity. minimum confidentiality assurance level of 0. Even for accounts with
a minimum confidentiality assurance level of 0, MUAs SHOULD attempt
TLS first if available, and MUST implement the ability 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 Note that if TLS is not used, or a version of TLS prior to TLS 1.1 is
described in Section 3.1 or a version of SSL/TLS prior to TLS 1.1 is negotiated, or the TLS server certificate is not successfully
used, the client MUST NOT present a high confidentiality indication validated as described in Section 3.1, the client MUST clearly
for the account or connection. indicate to the user that there is currently no assurance of
confidentiality for the mail account or connection.
3.3. Other Confidentiality Assurance Levels 3.3. Other Confidentiality Assurance Levels
This specification is not intended to limit experimentation and This specification is not intended to limit experimentation and
innovation with respect to user confidentiality. As a result more innovation with respect to user confidentiality. As a result, an
confidentiality assurance levels are permitted. However, levels implementation MAY implement confidentiality assurance levels other
below "no confidentiality assurance" described in the previous than those defined in this document, as long as those levels are
section are discouraged and implementers are cautioned that end users distinguished in user interfaces from those defined in this document,
may be confused by too many confidentiality assurance levels. and the ordering associated with them reflects the actual expectation
of confidentiality provided. However, implementation of levels below
confidentiality assurance level 0, as described in the previous
section, is discouraged. Implementers are also cautioned that end
users may be confused by too many confidentiality assurance levels.
As stated above, higher confidentiality assurance levels may be
standardized in the future. For example, a future confidentiality
assurance levels might require multiple independent trust anchors for
server certificate validation.
4. Implicit TLS 4. Implicit TLS
Previous standards for use of email protocols with TLS used the Previous standards for use of email protocols with TLS used the
STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With
STARTTLS, the client establishes a clear text application session and STARTTLS, the client establishes a clear text application session and
determines whether to issue a STARTTLS command based on server determines whether to issue a STARTTLS command based on server
capabilities and client configuration. If the client issues a capabilities and client configuration. If the client issues a
STARTTLS command, a TLS handshake follows that can upgrade the STARTTLS command, a TLS handshake follows that can upgrade the
connection. While this mechanism has been deployed, an alternate connection. While this mechanism has been deployed, an alternate
skipping to change at page 9, line 44 skipping to change at page 10, line 22
attacks could cause the loss of TLS 1.2 benefits. Only if client 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 policy is upgraded to require TLS 1.2 can the client prevent all
downgrade attacks. However, this sort of security policy upgrade downgrade attacks. However, this sort of security policy upgrade
will be ignored by most users unless it is automated. will be ignored by most users unless it is automated.
This section describes a mechanism, called "security directives", This section describes a mechanism, called "security directives",
which is designed to permit an MUA to recognize when a service which is designed to permit an MUA to recognize when a service
provider has committed to provide certain server security features, provider has committed to provide certain server security features,
and that it's safe for the client to change its configuration for and that it's safe for the client to change its configuration for
that account to require that such features be present in future that account to require that such features be present in future
sessions with that server. When an MUA implements both sessions with that server. Once the client has changed the
confidentiality assurance levels and security directives, then both configuration for a mail service to require specific server security
the end-user and the service provider independently have the ability features, those features are said to be "latched".
to improve the end-user's confidentiality.
Note that security directives are a separate mechanism from minimum
confidentiality assurance levels. A connection between a client and
a service MUST meet the requirements of both the minimum
confidentiality assurance level associated with the account, and the
conditions of any security directives established for that service.
Otherwise the client MUST abandon the connection. When an MUA
implements both minimum confidentiality assurance levels and security
directives, then both the end-user and the service provider
independently have the ability to improve the end-user's
confidentiality.
A security directive has the following formal syntax: A security directive has the following formal syntax:
directive = directive-name [ "=" directive-value ] directive = directive-name [ "=" directive-value ]
directive-name = token directive-name = token
directive-value = token directive-value = token
token = <As defined in RFC 7230> token = <As defined in RFC 7230>
skipping to change at page 10, line 41 skipping to change at page 11, line 30
a security connection problem. Server STS policy has the following a security connection problem. Server STS policy has the following
formal syntax: formal syntax:
sts-policy = [directive *(";" [SP] directive)] sts-policy = [directive *(";" [SP] directive)]
Protocol extensions to advertise STS policy for email servers are Protocol extensions to advertise STS policy for email servers are
defined in Section 9. defined in Section 9.
The IANA Considerations Section 13 defines a registry so that more The IANA Considerations Section 13 defines a registry so that more
directives can be defined in the future. Three initial directives directives can be defined in the future. Three initial directives
are defined for use by MUAs in Section 13.2: tls-version, sts-url and are defined for use by MUAs in Section 13.2: tls-version, sts-url,
tls-cert. and tls-cert.
7. Client Storage of Email Security Directives 7. Client Storage of Email Security Directives
Before a client can consider storing any security directives, it MUST Before a client can consider storing any security directives, it MUST
verify that the connection to the server uses TLS, the server has verify that the connection to the server uses TLS, the server has
been authenticated, and any requirements for any previously saved been authenticated, and any requirements for any previously saved
security directives are met. Then the client performs the following security directives are met. Then the client performs the following
steps for each security directive in the STS policy: steps for each security directive in the STS policy:
1. If the security directive name is not known to the client, skip 1. If the security directive name is not known to the client, skip
to the next directive. to the next directive.
2. If the security directive is already saved with the same value 2. If the security directive is already saved with the same value
(or a value considered greater than the current value in the (or a value considered greater than the current value in the
directive's definition), the client skips the security directive directive's definition), the client skips the security directive
and moves on to the next one. and moves on to the next one.
3. The client verifies the connection meets the requirements of the 3. The client verifies the connection meets the requirements of the
security directive. If the connection does not, then the security directive. If the connection does not, then the
directive will not be saved. directive will not be saved. For example, a security directive
claiming that the server supports tls-version 1.2 will not be
saved by a client if the currently negotiated TLS session is
using TLS 1.1.
4. If previous steps pass, the client SHOULD update the current 4. If previous steps pass, the client SHOULD update the current
account configuration to save the security directive. account configuration to save the security directive.
Once a security directive is saved, all subsequent connections to Once a security directive is saved, all subsequent connections to
that host require any associated security feature. For this that host require any associated security feature. For this
confidentiality protection to work as desired clients MUST NOT offer confidentiality protection to work as desired clients MUST NOT offer
a click-through-to-connect action when unable to achieve connection a click-through-to-connect action when unable to achieve connection
security matching the saved security directives. security matching the saved security directives.
skipping to change at page 14, line 25 skipping to change at page 15, line 19
"tls-cert=pkix") "tls-cert=pkix")
S: * ID ("name" "Demo Server" "version" "1.7" "sts-policy" S: * ID ("name" "Demo Server" "version" "1.7" "sts-policy"
"tls-version=1.1; "tls-version=1.1;
sts-url=<https://www.example.com/security-support.html>") sts-url=<https://www.example.com/security-support.html>")
S: a001 OK ID completed S: a001 OK ID completed
C: a002 LOGOUT C: a002 LOGOUT
Example 2 Example 2
This example shows a client that negotiated TLS, but was unable to This example shows a client that negotiated TLS, but was unable to
verify the server's certificate. The policy-failure informs the verify the server's certificate using PKIX. The policy-failure
server of this problem, at which point the client can disconnect. If informs the server of this problem, at which point the client can
the client had previously latched a URI for security problems from disconnect. If the client had previously saved the sts-url security
this server, it could offer to resolve that URI. However, the sts- directive from this server, it could offer to resolve that URI.
policy in this exchange is ignored due to the latch failure. However, the sts-policy in this exchange is ignored due to the
failure to meet the conditions of the tls-version security directive.
<IMAP Proxy connected over private network on port 143, there is <IMAP Proxy connected over private network on port 143, there is
a client connected to the proxy on port 993 that negotiated TLS> a client connected to the proxy on port 993 that negotiated TLS>
S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN
AUTH=SCRAM-SHA-1] hello AUTH=SCRAM-SHA-1] hello
C: a001 ID ("name" "Demo Mail" "version" "1.5" "saved" C: a001 ID ("name" "Demo Mail" "version" "1.5" "saved"
"tls-version=1.1; tls-cert=pkix" "tls-version=1.1; tls-cert=pkix"
"tls" "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256") "tls" "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256")
S: * ID ("name" "Demo Server" "version" "1.7" "sts-policy" S: * ID ("name" "Demo Server" "version" "1.7" "sts-policy"
"tls-version=1.1; tls-cert=pkix; "tls-version=1.1; tls-cert=pkix;
skipping to change at page 15, line 10 skipping to change at page 15, line 51
server. The client connected to the proxy and sent the ID command 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 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 command so the back-end server can log the cipher suite that was used
on the connection from the client. on the connection from the client.
9.2. POP DEEP Extension 9.2. POP DEEP Extension
POP servers supporting this specification MUST implement the POP3 POP servers supporting this specification MUST implement the POP3
extension mechanism [RFC2449]. POP servers MUST advertise the DEEP extension mechanism [RFC2449]. POP servers MUST advertise the DEEP
capability with an argument indicating the server's DEEP status. capability with an argument indicating the server's DEEP status.
(Note: DEEP is an ancronym for the original name of this
specification, before the terms were changed to align better with
those used in HSTS.)
<client connected to port 995 and negotiated TLS successfully> <client connected to port 995 and negotiated TLS successfully>
S: +OK POP server ready S: +OK POP server ready
C: CAPA C: CAPA
S: +OK Capability list follows S: +OK Capability list follows
S: TOP S: TOP
S: SASL PLAIN SCRAM-SHA-1 S: SASL PLAIN SCRAM-SHA-1
S: RESP-CODES S: RESP-CODES
S: PIPELINING S: PIPELINING
S: UIDL S: UIDL
S: STS tls-version=1.2 S: STS tls-version=1.2
sts-url=https://www.example.com/security-support.html> sts-url=<https://www.example.com/security-support.html>
S: . S: .
Example 4 Example 4
After verifying the TLS server certificate and issuing CAPA, the After verifying the TLS server certificate and issuing CAPA, the
client can save any or all of the STS policy. If the client connects client can save any or all of the STS policy. If the client connects
to this same server later and has a security failure, the client can to this same server later and has a security failure, the client can
direct the user's browser to the previously-saved URL where the direct the user's browser to the previously-saved URL where the
service provider can provide advice to the end user. service provider can provide advice to the end user.
skipping to change at page 16, line 7 skipping to change at page 17, line 7
SMTP Submission servers supporting this specification MUST implement SMTP Submission servers supporting this specification MUST implement
the MSTS SMTP extension. The name of this extension is MSTS. The the MSTS SMTP extension. The name of this extension is MSTS. The
EHLO keyword value is MSTS and the sts-policy ABNF is the syntax of EHLO keyword value is MSTS and the sts-policy ABNF is the syntax of
the EHLO keyword parameters. This does not add parameters to the the EHLO keyword parameters. This does not add parameters to the
MAIL FROM or RCPT TO commands. This also adds a CLIENT command to 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 SMTP which is used to report client information to the server. The
formal syntax for the command follows: formal syntax for the command follows:
deep-cmd = "CLIENT" 1*(SP deep-parameter) deep-cmd = "CLIENT" 1*(SP deep-parameter)
deep-parameter = name / version / latch / policy-fail deep-parameter = name / version / policy-fail
/ directives / tls / future-extension / directives / tls / future-extension
name = "name" SP esmtp-value name = "name" SP esmtp-value
version = "version" SP esmtp-value version = "version" SP esmtp-value
saved = "saved" SP directive-list saved = "saved" SP directive-list
policy-fail = "policy-fail" SP directive-list policy-fail = "policy-fail" SP directive-list
skipping to change at page 16, line 49 skipping to change at page 17, line 49
S: 250-example.com S: 250-example.com
S: 250-8BITMIME S: 250-8BITMIME
S: 250-PIPELINING S: 250-PIPELINING
S: 250-DSN S: 250-DSN
S: 250-AUTH PLAIN LOGIN S: 250-AUTH PLAIN LOGIN
S: 250-MSTS tls-version=1.2; tls-cert; S: 250-MSTS tls-version=1.2; tls-cert;
sts-url=<https://www.example.com/status.html> sts-url=<https://www.example.com/status.html>
S: 250-BURL imap S: 250-BURL imap
S: 250 SIZE 0 S: 250 SIZE 0
C: CLIENT name demo_submit version 1.5 saved "tls-version=1.1; C: CLIENT name demo_submit version 1.5 saved "tls-version=1.1;
tls-cert=pkix" directives "tls-version=1.2" tls-cert=pkix+dane" directives "tls-version=1.2"
S: 250 OK S: 250 OK
Example 5 Example 5
10. Account Setup Considerations 10. Account Setup Considerations
10.1. Use of SRV records in Establishing Configuration 10.1. Use of SRV records in Establishing Configuration
This section updates [RFC6186] by changing the preference rules and This section updates [RFC6186] by changing the preference rules and
adding a new SRV service label _submissions._tcp to refer to Message adding a new SRV service label _submissions._tcp to refer to Message
Submission with implicit TLS. Submission with implicit TLS.
User-configurable MUAs SHOULD support use of [RFC6186] for account User-configurable MUAs SHOULD support use of [RFC6186] for account
setup. However, when using configuration information obtained by setup. However, when using configuration information obtained by
this method, MUAs SHOULD default to a high confidentiality assurance this method, MUAs SHOULD default to a minimum confidentiality
level, unless the user has explicitly requested reduced assurance level of 1, unless the user has explicitly requested
confidentiality. This will have the effect of causing the MUA to reduced confidentiality. This will have the effect of causing the
ignore advertised configurations that do not support TLS, even when MUA to ignore advertised configurations that do not support TLS, even
those advertised configurations have a higher priority than other when those advertised configurations have a higher priority than
advertised configurations. other advertised configurations.
When using [RFC6186] configuration information, Mail User Agents When using [RFC6186] configuration information, Mail User Agents
SHOULD NOT automatically establish new configurations that do not SHOULD NOT automatically establish new configurations that do not
require TLS for all servers, unless there are no advertised require TLS for all servers, unless there are no advertised
configurations using TLS. If such a configuration is chosen, prior configurations using TLS. If such a configuration is chosen, prior
to attempting to authenticate to the server or use the server for to attempting to authenticate to the server or use the server for
message submission, the MUA SHOULD warn the user that traffic to that message submission, the MUA SHOULD warn the user that traffic to that
server will not be encrypted and that it will therefore likely be server will not be encrypted and that it will therefore likely be
intercepted by unauthorized parties. The specific wording is to be intercepted by unauthorized parties. The specific wording is to be
determined by the implementation, but it should adequately capture determined by the implementation, but it should adequately capture
skipping to change at page 18, line 24 skipping to change at page 19, line 24
that certificate and the saved host name for the server. This is that certificate and the saved host name for the server. This is
called certificate pinning. Certificate pinning is only appropriate called certificate pinning. Certificate pinning is only appropriate
during account setup and MUST NOT be offered in response to a failed during account setup and MUST NOT be offered in response to a failed
certificate validation for an existing account. An MUA that allows certificate validation for an existing account. An MUA that allows
certificate pinning MUST NOT allow a certificate pinned for one certificate pinning MUST NOT allow a certificate pinned for one
account to validate connections for other accounts. account to validate connections for other accounts.
A pinned certificate is subject to a man-in-the-middle attack at A pinned certificate is subject to a man-in-the-middle attack at
account setup time, and lacks a mechanism to revoke or securely account setup time, and lacks a mechanism to revoke or securely
refresh the certificate. Therefore use of a pinned certificate does refresh the certificate. Therefore use of a pinned certificate does
not provide a high confidentiality assurance and an MUA MUST NOT not meet the requirement for a minimum confidentiality assurance
indicate a high level for an account or connection using a pinned level of 1, and an MUA MUST NOT indicate a confidentiality assurance
certificate. Additional advice on certificate pinning is present in level of 1 for an account or connection using a pinned certificate.
[RFC6125]. Additional advice on certificate pinning is present in [RFC6125].
11. Implementation Requirements 11. Implementation Requirements
This section details requirements for implementations of electronic This section details requirements for implementations of electronic
mail protocol clients and servers. A requirement for a client or mail protocol clients and servers. A requirement for a client or
server implementation to support a particular feature is not the same server implementation to support a particular feature is not the same
thing as a requirement that a client or server running a conforming thing as a requirement that a client or server running a conforming
implementation be configured to use that feature. Requirements for implementation be configured to use that feature. Requirements for
Mail Service Providers (MSPs) are distinct from requirements for Mail Service Providers (MSPs) are distinct from requirements for
protocol implementations, and are listed in a separate section. protocol implementations, and are listed in a separate section.
11.1. All Implementations (Client and Server) 11.1. All Implementations (Client and Server)
These requirements apply to MUAs as well as POP, IMAP and SMTP These requirements apply to MUAs as well as POP, IMAP and SMTP
Submission servers. Submission servers.
o All implementations MUST be configurable to support implicit TLS o All implementations MUST implement TLS 1.2 or later, and be
using the TLS 1.2 protocol or later [RFC5246]. configurable to support implicit TLS using the TLS 1.2 protocol or
later [RFC5246].
o All implementations MUST implement the recommended cipher suites o All implementations MUST implement the recommended cipher suites
described in [RFC7525] or a future BCP or standards track revision described in [RFC7525] or a future BCP or standards track revision
of that document. of that document.
o All implementations MUST be configurable to require TLS before o All implementations MUST be configurable to require TLS before
performing any operation other than capability discovery and performing any operation other than capability discovery and
STARTTLS. STARTTLS.
o The IMAP specification [RFC3501] is hereby modified to revoke the o The IMAP specification [RFC3501] is hereby modified to revoke the
skipping to change at page 20, line 5 skipping to change at page 21, line 10
client certificate authentication with implicit TLS MUST implement client certificate authentication with implicit TLS MUST implement
the SASL EXTERNAL [RFC4422] mechanism using the appropriate the SASL EXTERNAL [RFC4422] mechanism using the appropriate
authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP
Submission [RFC4954], AUTHENTICATE for IMAP [RFC3501]). Submission [RFC4954], AUTHENTICATE for IMAP [RFC3501]).
11.2. Mail Server Implementation Requirements 11.2. Mail Server Implementation Requirements
These requirements apply to servers that implement POP, IMAP or SMTP These requirements apply to servers that implement POP, IMAP or SMTP
Submission. Submission.
o Servers MUST implement the DEEP extension described in Section 9 o Servers MUST implement the appropriate STS Policy and Reporting
extensions described in Section 9
o IMAP and SMTP submission servers SHOULD implement and be o IMAP and SMTP submission servers SHOULD implement and be
configurable to support STARTTLS. This enables discovery of new configurable to support STARTTLS. This enables discovery of new
TLS availability, and can increase usage of TLS by legacy clients. TLS availability, and can increase usage of TLS by legacy clients.
o Servers MUST NOT advertise STARTTLS if it is unlikely to succeed o Servers MUST NOT advertise STARTTLS capability if it is unlikely
based on server configuration (e.g., there is no server to succeed based on server configuration (e.g., there is no server
certificate installed). certificate installed).
o SMTP message submission servers that have negotiated TLS SHOULD o SMTP message submission servers that have negotiated TLS SHOULD
add a Received header field to the message including the tls add a Received header field to the message including the tls
clause described in Section 8. clause described in Section 8.
o Servers MUST be configurable to include the TLS cipher information o Servers MUST be configurable to include the TLS cipher information
in any connection or user logging or auditing facility they in any connection or user logging or auditing facility they
provide. provide.
11.3. Mail User Agent Implementation Requirements 11.3. Mail User Agent Implementation Requirements
This section describes requirements on Mail User Agents (MUAs) using This section describes requirements on Mail User Agents (MUAs) using
IMAP, POP, and/or Submission protocols. Note: Requirements IMAP, POP, and/or Submission protocols. Note: Requirements
pertaining to use of Submission servers are also applicable to use of pertaining to use of Submission servers are also applicable when
SMTP servers (e.g., port 25) for mail submission. using SMTP servers (e.g., port 25) for mail submission.
o User agents SHOULD indicate to users at configuration time, the o User agents SHOULD indicate to users at configuration time, the
expected level of confidentiality based on appropriate security minimum expected level of confidentiality based on appropriate
inputs such as which security directives are pre-set, the number security inputs such as which security directives are pre-set, the
of trust anchors, certificate validity, use of an extended number of trust anchors, certificate validity, use of an extended
validation certificate, TLS version supported, and TLS cipher validation certificate, TLS version supported, and TLS cipher
suites supported by both server and client. This indication suites supported by both server and client. This indication
SHOULD also be present when editing or viewing account SHOULD also be present when editing or viewing account
configuration. configuration.
o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes o For any mail service not initially configured to require TLS, MUAs
available for a protocol and set the tls-version=1.1 directive if SHOULD detect when STARTTLS and/or implicit TLS becomes available
the server advertises the tls-version=1.1 security policy after a for a protocol and set the tls-version security directive if the
successful TLS negotiation. server advertises the tls-version=1.1 or higher security policy
after a successful negotiation (including certificate validation)
of TLS 1.1.
o Whenever requested to establish any configuration that does not o Whenever requested to establish any configuration that does not
require both TLS and server certificate verification to talk to a require both TLS and server certificate verification to talk to a
server or account, an MUA SHOULD warn its user that his or her server or account, an MUA SHOULD warn its user that his or her
mail traffic (including password, if applicable) will be exposed mail traffic (including password, if applicable) will be exposed
to attackers, and give the user an opportunity to abort the to attackers, and give the user an opportunity to abort the
connection prior to transmission of any such password or traffic. connection prior to transmission of any such password or traffic.
o MUAs SHOULD implement the "tls-version=1.2" security directive o MUAs SHOULD support the ability to save the "tls-version=1.2"
(the TLS library has to provide an API that controls permissible security directive (the TLS library has to provide an API that
TLS versions and communicates the negotiated TLS protocol version controls permissible TLS versions, and communicates the negotiated
to the application for this to be possible). TLS protocol version to the application, for this to be possible).
o See Section 3 for additional requirements. o See Section 3 for additional requirements.
11.4. Non-configurable MUAs and nonstandard access protocols 11.4. Non-configurable MUAs and nonstandard access protocols
MUAs which are not configurable to use user-specified servers MUST MUAs which are not configurable to use user-specified servers MUST
implement TLS or similarly other strong encryption mechanism when implement TLS or similarly other strong encryption mechanism when
communicating with their mail servers. This generally applies to communicating with their mail servers. This generally applies to
MUAs that are pre-configured to operate with one or more specific MUAs that are pre-configured to operate with one or more specific
services, whether or not supplied by the vendor of those services. services, whether or not supplied by the vendor of those services.
MUAs using protocols other than IMAP, POP, and Submission to MUAs using protocols other than IMAP, POP, and Submission to
communicate with mail servers, MUST implement TLS or other similarly communicate with mail servers, MUST implement TLS or other similarly
robust encryption mechanism in conjunction with those protocols. robust encryption mechanism in conjunction with those protocols.
11.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services 11.5. Compliance for Anti-Virus/Anti-Spam Software and Services
There are multiple ways to connect an Anti-Virus and/or Anti-Spam 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- (AVAS) service to a mail server. Some mechanisms, such as the de-
facto milter protocol do not impact DEEP. However, some services use facto milter protocol, are out of scope for this specification.
an SMTP relay proxy that intercepts mail at the application layer to However, some services use an SMTP relay proxy that intercepts mail
perform a scan and proxy or forward to another MTA. Deploying AVAS at the application layer to perform a scan and proxy or forward to
services in this way can cause many problems [RFC2979] including another MTA. Deploying AVAS services in this way can cause many
direct interference with DEEP and confidentiality or security problems [RFC2979] including direct interference with this
reduction. An AVAS product or service is considered DEEP compliant specification, and other forms of confidentiality or security
if all IMAP, POP and SMTP-related software it includes is DEEP reduction. An AVAS product or service is considered compliant with
compliant and it advertises and supports all security directives that this specification if all IMAP, POP and SMTP-related software
the actual servers advertise. (including proxies) it includes are compliant with this
specification, and each of these services advertise and support all
security directives that the actual end-servers advertise.
Note that end-to-end email encryption prevents AVAS software and Note that end-to-end email encryption prevents AVAS software and
services from using email content as part of a spam or virus services from using email content as part of a spam or virus
assessment. Furthermore, while DEEP high confidentiality assurance assessment. Furthermore, while a minimum confidentiality assurance
can prevent a man-in-the-middle from introducing spam or virus level of 1 or better can prevent a man-in-the-middle from introducing
content between the MUA and Submission server, it does not prevent spam or virus content between the MUA and Submission server, it does
other forms of client or account compromise so use of AVAS services not prevent other forms of client or account compromise. Use of AVAS
for submitted email remains necessary. services for submitted email therefore remains necessary.
12. Mail Service Provider Requirements 12. Mail Service Provider Requirements
This section details requirements for providers of IMAP, POP, and/or This section details requirements for providers of IMAP, POP, and/or
SMTP submission services, for providers who claim to conform to this SMTP submission services, for providers who claim to conform to this
specification. specification.
12.1. Server Requirements 12.1. Server Requirements
Mail Service Providers MUST use server implementations that conform Mail Service Providers MUST use server implementations that conform
skipping to change at page 23, line 45 skipping to change at page 25, line 5
MSPs SHOULD regularly and frequently monitor their various servers to MSPs SHOULD regularly and frequently monitor their various servers to
make sure that: TLS server certificates remain valid and are not make sure that: TLS server certificates remain valid and are not
about to expire, TLSA records match the public keys advertised in about to expire, TLSA records match the public keys advertised in
server certificates, are signed using DNSSEC, server configurations server certificates, are signed using DNSSEC, server configurations
are consistent with SRV advertisements, and DNSSEC signatures are are consistent with SRV advertisements, and DNSSEC signatures are
valid and verifiable. Failure to detect expired certificates and DNS valid and verifiable. Failure to detect expired certificates and DNS
configuration errors in a timely fashion can result in significant configuration errors in a timely fashion can result in significant
loss of service for an MSP's users and a significant support burden loss of service for an MSP's users and a significant support burden
for the MSP. for the MSP.
12.6. Advertisement of DEEP status 12.6. Advertisement of STS policies
MSPs SHOULD advertise a DEEP status that includes tls11, tls-cert and MSPs SHOULD advertise STS policies that include at least tls11, tls-
an HTTPS URL that can be used to inform clients of service outages or cert and sts-url, with the latter having an associated https URL that
problems impacting client confidentiality. Note that advertising can be used to inform clients of service outages or problems
tls-cert is a commitment to maintain and renew server certificates. impacting client confidentiality. Note that advertising tls-cert is
a commitment to maintain and renew server certificates. A MSP MAY
also specifically indicate a commitment to support PKIX validation,
DANE validation, or both, using tls-cert=pkix, tls-cert=dane, or tls-
cert=pkix+dane, respectively.
12.7. Require TLS 12.7. Require TLS
New servers and services SHOULD be configured to require TLS unless New servers and services SHOULD be configured to require TLS unless
it's necessary to support legacy clients or existing client it's necessary to support legacy clients or existing client
configurations. configurations.
12.8. Changes to Internet Facing Servers 12.8. Changes to Internet Facing Servers
When an MSP changes the Internet Facing Servers providing mail access When an MSP changes the Internet Facing Servers providing mail access
skipping to change at page 25, line 42 skipping to change at page 27, line 4
if the version is unrecognized. if the version is unrecognized.
Description: This directive indicates that the TLS version Description: This directive indicates that the TLS version
negotiated must be the specified version or later. In the event negotiated must be the specified version or later. In the event
this directive is saved and only an older TLS version is this directive is saved and only an older TLS version is
available, that results in STS policy failure. available, that results in STS policy failure.
Scope: MUA only Scope: MUA only
Intended Usage: COMMON Intended Usage: COMMON
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Submitter: Authors of this document Submitter: Authors of this document
Change Controller: IESG Change Controller: IESG
Name: tls-cert Name: tls-cert
Value: Optional; pkix refers to PKIX certificate validation, dane Value: Optional; pkix refers to PKIX certificate validation; dane
refers to DANE certificate validation, any refers to any refers to DANE certificate validation; pkix+dane refers to use of
validation mechanism the client considers acceptable. If no value both PKIX and DANE validation; any refers to any validation method
is provided, "any" is assumed. the client considers acceptable. If no value is supplied, "any"
is assumed.
Description: This directive indicates that TLS was successfully Description: This directive indicates that TLS was successfully
negotiated and the server certificate was successfully verified by negotiated and the server certificate was successfully verified by
the client using PKIX [RFC5280] or DANE [RFC6698] and the server the client [RFC5280] and the server certificate identity was
certificate identity was verified using the algorithm appropriate verified using the algorithm appropriate for the protocol (see
for the protocol (see Section 4). This directive is saved if the Section 4). This directive is saved if the client sees this in
client sees this in the advertised server STS policy after the advertised server STS policy after successfully negotiating
successfully negotiating TLS and verifying the certificate and TLS and verifying the certificate and server identity using a
server identity. For the HSTS protocol, this directive (with the means consistent with the associated (or implied) value. Note
"any" value) is implied by the presence of the Strict-Transport- that an advertisement of either tls-cert=pkix or tls-
Security header, as a result it is never specified in that cert=pkix+dane in a server's STS policy indicates that the server
protocol. commits to using certificates that are verifiable using PKIX in
the future, but tls-cert=pkix implies no commitment regarding DANE
support. Similarly, an advertisement of either tls-cert=dane or
tls-cert=pkix+dane indicates that the server commits to using
certificates that are verifiable using DANE in the future, but
tls-cert=dane implies no commitment regarding PKIX support. An
advertisement of tls-cert or tls-cert=any indicates only that the
server will continue to provide valid server certificates, but
makes no commitment about the means of verifiability. (For the
HSTS protocol, the presence of a Strict-Transport-Security
response header serves as an indication that the certificate
should be valid, so the tls-cert directive is never specified in
that protocol.)
Scope: MUA only Scope: MUA only
Intended Usage: COMMON Intended Usage: COMMON
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Submitter: Authors of this document Submitter: Authors of this document
Change Controller: IESG Change Controller: IESG
skipping to change at page 27, line 49 skipping to change at page 29, line 17
IANA is asked to update the registration of the TCP well-known port IANA is asked to update the registration of the TCP well-known port
995 using the following template ([RFC6335]): 995 using the following template ([RFC6335]):
Service Name: pop3s Service Name: pop3s
Transport Protocol: TCP Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org> Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: POP3 over TLS protocol Description: POP3 over TLS protocol
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Port Number: 995
Service Name: pop3s
Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: POP3 over TLS protocol
Reference: RFC XXXX (this document once published)
13.4. IMAPS Port Registration Update 13.4. IMAPS Port Registration Update
IANA is asked to update the registration of the TCP well-known port IANA is asked to update the registration of the TCP well-known port
993 using the following template ([RFC6335]): 993 using the following template ([RFC6335]):
Service Name: imaps Service Name: imaps
Transport Protocol: TCP Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org> Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: IMAP over TLS protocol Description: IMAP over TLS protocol
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Port Number: 993
Service Name: imaps
Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: IMAP over TLS protocol
Reference: RFC XXXX (this document once published)
13.5. Submissions Port Registration 13.5. Submissions Port Registration
IANA is asked to assign an alternate usage of port 465 in addition to IANA is asked to assign an alternate usage of port 465 in addition to
the current assignment using the following template ([RFC6335]): the current assignment using the following template ([RFC6335]):
Service Name: submissions Service Name: submissions
Transport Protocol: TCP Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org> Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: Message Submission over TLS protocol Description: Message Submission over TLS protocol
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Port Number: 465
Service Name: submissions
Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: Message Submission over TLS protocol
Reference: RFC XXXX (this document once published)
This is a one time procedural exception to the rules in RFC 6335. This is a one time procedural exception to the rules in RFC 6335.
This requires explicit IESG approval and does not set a precedent. This requires explicit IESG approval and does not set a precedent.
Historically, port 465 was briefly registered as the "smtps" port. Historically, port 465 was briefly registered as the "smtps" port.
This registration made no sense as the SMTP transport MX This registration made no sense as the SMTP transport MX
infrastructure has no way to specify a port so port 25 is always infrastructure has no way to specify a port so port 25 is always
used. As a result, the registration was revoked and was subsequently used. As a result, the registration was revoked and was subsequently
reassigned to a different service. In hindsight, the "smtps" reassigned to a different service. In hindsight, the "smtps"
registration should have been renamed or reserved rather than registration should have been renamed or reserved rather than
revoked. Unfortunately, some widely deployed mail software revoked. Unfortunately, some widely deployed mail software
skipping to change at page 30, line 50 skipping to change at page 31, line 45
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<http://www.rfc-editor.org/info/rfc1939>. <http://www.rfc-editor.org/info/rfc1939>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, DOI 10.17487/RFC2449, November 1998, Mechanism", RFC 2449, DOI 10.17487/RFC2449, November 1998,
<http://www.rfc-editor.org/info/rfc2449>. <http://www.rfc-editor.org/info/rfc2449>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971,
DOI 10.17487/RFC2971, October 2000, DOI 10.17487/RFC2971, October 2000,
<http://www.rfc-editor.org/info/rfc2971>. <http://www.rfc-editor.org/info/rfc2971>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <http://www.rfc-editor.org/info/rfc3207>. February 2002, <http://www.rfc-editor.org/info/rfc3207>.
skipping to change at page 31, line 39 skipping to change at page 32, line 33
Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034, Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034,
July 2007, <http://www.rfc-editor.org/info/rfc5034>. July 2007, <http://www.rfc-editor.org/info/rfc5034>.
[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T.
Finch, "Email Submission Operations: Access and Finch, "Email Submission Operations: Access and
Accountability Requirements", BCP 134, RFC 5068, Accountability Requirements", BCP 134, RFC 5068,
DOI 10.17487/RFC5068, November 2007, DOI 10.17487/RFC5068, November 2007,
<http://www.rfc-editor.org/info/rfc5068>. <http://www.rfc-editor.org/info/rfc5068>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
skipping to change at page 32, line 20 skipping to change at page 33, line 14
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>. <http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, DOI 10.17487/ Submission/Access Services", RFC 6186,
RFC6186, March 2011, DOI 10.17487/RFC6186, March 2011,
<http://www.rfc-editor.org/info/rfc6186>. <http://www.rfc-editor.org/info/rfc6186>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<http://www.rfc-editor.org/info/rfc6409>. <http://www.rfc-editor.org/info/rfc6409>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, DOI 10.17487/ Transport Security (HSTS)", RFC 6797,
RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>. <http://www.rfc-editor.org/info/rfc6797>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
May 2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, (DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
[RFC7817] Melnikov, A., "Updated TLS Server Identity Check Procedure [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
for Email Related Protocols", RFC 7817, March 2016, Server Identity Check Procedure for Email-Related
Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
<http://www.rfc-editor.org/info/rfc7817>. <http://www.rfc-editor.org/info/rfc7817>.
15.2. Informative References 15.2. Informative References
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999, RFC 2595, DOI 10.17487/RFC2595, June 1999,
<http://www.rfc-editor.org/info/rfc2595>. <http://www.rfc-editor.org/info/rfc2595>.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet [RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
skipping to change at page 33, line 24 skipping to change at page 34, line 24
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004,
<http://www.rfc-editor.org/info/rfc3848>. <http://www.rfc-editor.org/info/rfc3848>.
[RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887,
DOI 10.17487/RFC3887, September 2004, DOI 10.17487/RFC3887, September 2004,
<http://www.rfc-editor.org/info/rfc3887>. <http://www.rfc-editor.org/info/rfc3887>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/ (TLS) Protocol Version 1.1", RFC 4346,
RFC4346, April 2006, DOI 10.17487/RFC4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>. <http://www.rfc-editor.org/info/rfc4346>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006, DOI 10.17487/RFC4422, June 2006,
<http://www.rfc-editor.org/info/rfc4422>. <http://www.rfc-editor.org/info/rfc4422>.
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954, DOI 10.17487/ Extension for Authentication", RFC 4954,
RFC4954, July 2007, DOI 10.17487/RFC4954, July 2007,
<http://www.rfc-editor.org/info/rfc4954>. <http://www.rfc-editor.org/info/rfc4954>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>. <http://www.rfc-editor.org/info/rfc5598>.
[RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804,
July 2010, <http://www.rfc-editor.org/info/rfc5804>. July 2010, <http://www.rfc-editor.org/info/rfc5804>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
March 2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
August 2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
Appendix A. Design Considerations Appendix A. Design Considerations
This section is not normative. This section is not normative.
The first version of this was written independently from The first version of this was written independently from draft-moore-
draft-moore-email-tls-00.txt; subsequent versions merge ideas from email-tls-00.txt; subsequent versions merge ideas from both drafts.
both drafts.
One author of this document was also the author of RFC 2595 that 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 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 author was perhaps the first to propose that idea. In hindsight both
authors now believe that that approach was a mistake. At this point authors now believe that that approach was a mistake. At this point
the authors believe that while anything that makes it easier to the authors believe that while anything that makes it easier to
deploy TLS is good, the desirable end state is that these protocols deploy TLS is good, the desirable end state is that these protocols
always use TLS, leaving no need for a separate port for cleartext always use TLS, leaving no need for a separate port for cleartext
operation except to support legacy clients while they continue to be operation except to support legacy clients while they continue to be
used. The separate port model for TLS is inherently simpler to used. The separate port model for TLS is inherently simpler to
skipping to change at page 35, line 45 skipping to change at page 36, line 45
contrary to the goal of promoting more TLS use. Encouraging use of contrary to the goal of promoting more TLS use. Encouraging use of
STARTTLS on port 587 would not create interoperability problems, but STARTTLS on port 587 would not create interoperability problems, but
is unlikely to have impact on current undocumented use of port 465 is unlikely to have impact on current undocumented use of port 465
and makes the guidance in this document less consistent. The and makes the guidance in this document less consistent. The
remaining option is to document the current state of the world and remaining option is to document the current state of the world and
support future use of port 465 for submission as this increases support future use of port 465 for submission as this increases
consistency and ease-of-deployment for TLS email submission. consistency and ease-of-deployment for TLS email submission.
Appendix B. Change Log Appendix B. Change Log
Changes since draft-ietf-uta-email-deep-05:
o Clarify throughout that the confidentiality assurance level
associated with a mail account is a minimum level; attempt to
distinguish this from the current confidentiality level provided
by a connection between client and server.
o Change naming for confidentiality assurance levels: instead of
"high" or "no" confidence, assign numbers 1 and 0 to them
respectively. This because it seems likely that in the not-too-
distant future, what was defined in -05 as "high" confidence will
be considered insufficient, and calling that "high" confidence
will become misleading. For example, relying entirely on a list
of trusted CAs to validate server certificates from arbitrary
parties, appears to be less and less reliable in practice at
thwarting MITM attacks.
o Clarify that if some services associated with a mail account don't
meet the minimium confidentiality assurance level assigned to that
account, other services that do meet that minimum confidentiality
assurance level may continue to be used.
o Clarify that successful negotiation of at least TLS version 1.1 is
required as a condition of meeting confidentiality assurance level
1.
o Clarify that validation of a server certificate using either DANE
or PKIX is sufficient to meet the certificate validation
requirement of confidentiality assurance level 1.
o Clarify that minimum confidentiality assurance levels are separate
from security directives, and that the requrements of both
mechanisms must be met.
o Explicitly cite an example that a security directive of tls-
version=1.2 won't be saved if the currently negotiated tls-version
is 1.1. (This example already appeared a bit later in the text,
but for author KM it seemed to make the mechanism clearer to use
this example earlier.)
o Clarify some protocol examples as to whether PKIX or DANE was used
to verify a server's certificate.
o Remove most references to DEEP as the conversion from DEEP to MUA-
STS seemed incomplete, but kept the DEEP command for use in POP3
on the assumption that author CN wanted it that way.
o Removed most references to "latch" and derivative words.
o Added pkix+dane as a value for the tls-cert directive, to indicate
(from a server) that both PKIX and DANE validation will be
supported, or (from a client) that both PKIX and DANE were used to
validate a certificate. Also clarified what each of any, pkix,
dane, and pkix+dane mean when advertised by a server and in
particular that tls-cert=any provides no assurance of future PKIX
verifiability in contrast to tls-cert=pkix or tls-cert=pkix+dane.
It seemed important to support the ability to evolve to using
multiple trust anchors for certificate validation, but also to
allow servers to have the option to migrate from PKIX to DANE if
that made sense for them. This change seemed less disruptive than
either defining additional directives, or allowing multiple
instances of the same directive with different values to appear in
the same advertisement.
o Clarify interaction of this specification with anti-virus / anti-
spam mechanisms.
Changes since draft-ietf-uta-email-deep-04: Changes since draft-ietf-uta-email-deep-04:
o Swap sections 5.1 and 5.3 ("Email Security Tags" and "Server DEEP o Swap sections 5.1 and 5.3 ("Email Security Tags" and "Server DEEP
Status") as that order may aid understanding of the model. Also Status") as that order may aid understanding of the model. Also
rewrote parts of these two sections to try to make the model rewrote parts of these two sections to try to make the model
clearer. clearer.
o Add text about versioning of security tags to make the model o Add text about versioning of security tags to make the model
clearer. clearer.
skipping to change at page 39, line 6 skipping to change at page 41, line 27
o Added reference to HSTS. o Added reference to HSTS.
Changes since -00: Changes since -00:
o Rewrote introduction to merge ideas from draft-moore-email-tls-00. o Rewrote introduction to merge ideas from draft-moore-email-tls-00.
o Added Implicit TLS section, Account configuration section and IANA o Added Implicit TLS section, Account configuration section and IANA
port registration updates based on draft-moore-email-tls-00. port registration updates based on draft-moore-email-tls-00.
o Add protocol details necessary to standardize implicit TLS for o Add protocol details necessary to standardize implicit TLS for
POP/IMAP/submission, using ideas from POP/IMAP/submission, using ideas from draft-melnikov-pop3-over-
draft-melnikov-pop3-over-tls. tls.
o Reduce initial set of security tags based on feedback. o Reduce initial set of security tags based on feedback.
o Add deep status concept to allow a window for software updates to o Add deep status concept to allow a window for software updates to
be backed out before latches make that problematic, as well as to be backed out before latches make that problematic, as well as to
provide service providers with a mechanism they can use to assist provide service providers with a mechanism they can use to assist
customers in the event of a privacy failure. customers in the event of a privacy failure.
o Add DNS SRV section from draft-moore-email-tls-00. o Add DNS SRV section from draft-moore-email-tls-00.
o Write most of the missing IANA considerations section. o Write most of the missing IANA considerations section.
o Rewrite most of implementation requirements section based more on o Rewrite most of implementation requirements section based more on
draft-moore-email-tls-00. Remove new cipher requirements for now draft-moore-email-tls-00. Remove new cipher requirements for now
because those may be dealt with elsewhere. because those may be dealt with elsewhere.
Appendix C. Acknowledgements Appendix C. Acknowledgements
Thanks to Ned Freed for discussion of the initial latch concepts in Thanks to Ned Freed for discussion of the initial latch concepts in
this document. Thanks to Alexey Melnikov for this document. Thanks to Alexey Melnikov for draft-melnikov-pop3-
draft-melnikov-pop3-over-tls-02, which was the basis of the POP3 over-tls-02, which was the basis of the POP3 implicit TLS text.
implicit TLS text. Thanks to Russ Housley, Alexey Melnikov and Dan Thanks to Russ Housley, Alexey Melnikov and Dan Newman for review
Newman for review feedback. Thanks to Paul Hoffman for interesting feedback. Thanks to Paul Hoffman for interesting feedback in initial
feedback in initial conversations about this idea. conversations about this idea.
Authors' Addresses Authors' Addresses
Keith Moore Keith Moore
Network Heretics Network Heretics
PO Box 1934 PO Box 1934
Knoxville, TN 37901 Knoxville, TN 37901
US US
Email: moore@network-heretics.com Email: moore@network-heretics.com
 End of changes. 67 change blocks. 
263 lines changed or deleted 405 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/