draft-ietf-uta-email-deep-04.txt   draft-ietf-uta-email-deep-05.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 March 17, 2016 Intended status: Standards Track July 9, 2016
Expires: September 18, 2016 Expires: January 10, 2017
Deployable Enhanced Email Privacy (DEEP) Mail User Agent Strict Transport Security (MUA-STS)
draft-ietf-uta-email-deep-04.txt draft-ietf-uta-email-deep-05.txt
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, provide a model for mail user Layer Security (TLS) technology and provides a model for a mail user
agent's confidentiality assurance, and enable mail service providers agent's confidentiality assurance. This enables mail service
to advertise improved TLS confidentiality facilities. providers to advertise strict transport security (STS) policies that
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 September 18, 2016. This Internet-Draft will expire on January 10, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 14 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . 5
3.1. High Confidentiality Assurance . . . . . . . . . . . . . 6 3.1. High Confidentiality Assurance . . . . . . . . . . . . . . 6
3.2. No Confidentiality Assurance . . . . . . . . . . . . . . 6 3.2. No Confidentiality Assurance . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 7
4.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 7 4.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 7
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 Latches . . . . . . . 9 5. Email Security Upgrading Using Security Directives . . . . . . 9
5.1. Email Security Tags . . . . . . . . . . . . . . . . . . . 10 6. Server Strict Transport Security Policy . . . . . . . . . . . 10
5.2. Initial Set of Email Security Tags . . . . . . . . . . . 10 7. Client Storage of Email Security Directives . . . . . . . . . 10
5.3. Server DEEP Status . . . . . . . . . . . . . . . . . . . 10 7.1. Security Directive Upgrade Example . . . . . . . . . . . . 11
5.4. Email Security Tag Latch Failures . . . . . . . . . . . . 11 7.2. Security Policy Failures . . . . . . . . . . . . . . . . . 11
6. Recording TLS Cipher Suite in Received Header . . . . . . . . 11 8. Recording TLS Cipher Suite in Received Header . . . . . . . . 12
7. Extensions for DEEP Status and Reporting . . . . . . . . . . . 12 9. Extensions for STS Policy and Reporting . . . . . . . . . . . 12
7.1. IMAP DEEP Extension . . . . . . . . . . . . . . . . . . . 12 9.1. IMAP STS Extension . . . . . . . . . . . . . . . . . . . . 12
7.2. POP DEEP Extension . . . . . . . . . . . . . . . . . . . 14 9.2. POP DEEP Extension . . . . . . . . . . . . . . . . . . . . 15
7.3. SMTP DEEP Extension . . . . . . . . . . . . . . . . . . . 15 9.3. SMTP MSTS Extension . . . . . . . . . . . . . . . . . . . 15
7.4. SMTP Error Extension . . . . . . . . . . . . . . . . . . 17 10. Account Setup Considerations . . . . . . . . . . . . . . . . . 17
8. Account Setup Considerations . . . . . . . . . . . . . . . . . 17 10.1. Use of SRV records in Establishing Configuration . . . . . 17
8.1. Use of SRV records in Establishing Configuration . . . . 17 10.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 18
8.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 18 11. Implementation Requirements . . . . . . . . . . . . . . . . . 18
9. Implementation Requirements . . . . . . . . . . . . . . . . . 18 11.1. All Implementations (Client and Server) . . . . . . . . . 18
9.1. All Implementations (Client and Server) . . . . . . . . . 19 11.1.1. Client Certificate Authentication . . . . . . . . . . 19
9.1.1. Client Certificate Authentication . . . . . . . . . . 19 11.2. Mail Server Implementation Requirements . . . . . . . . . 19
9.2. Mail Server Implementation Requirements . . . . . . . . . 20 11.3. Mail User Agent Implementation Requirements . . . . . . . 20
9.3. Mail User Agent Implementation Requirements . . . . . . . 20 11.4. Non-configurable MUAs and nonstandard access protocols . . 21
9.4. Non-configurable MUAs and nonstandard access protocols . 21 11.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and
9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services . . . . . . . . . . . . . . . . . . . . . . . . . 21
Services . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Mail Service Provider Requirements . . . . . . . . . . . . . . 21
10. Mail Service Provider Requirements . . . . . . . . . . . . . . 22 12.1. Server Requirements . . . . . . . . . . . . . . . . . . . 22
10.1. Server Requirements . . . . . . . . . . . . . . . . . . . 22 12.2. MSPs MUST provide Submission Servers . . . . . . . . . . . 22
10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 22 12.3. TLS Server Certificate Requirements . . . . . . . . . . . 22
10.3. TLS Server Certificate Requirements . . . . . . . . . . . 22 12.4. Recommended DNS records for mail protocol servers . . . . 22
10.4. Recommended DNS records for mail protocol servers . . . . 23 12.4.1. MX records . . . . . . . . . . . . . . . . . . . . . 23
10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . . 23 12.4.2. SRV records . . . . . . . . . . . . . . . . . . . . . 23
10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . . 23 12.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 23
10.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 23 12.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . 23
10.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . . 23 12.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . . 23
10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . . 23 12.6. Advertisement of DEEP status . . . . . . . . . . . . . . . 23
10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 24 12.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . . 24
10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . . 24 12.8. Changes to Internet Facing Servers . . . . . . . . . . . . 24
10.8. Changes to Internet Facing Servers . . . . . . . . . . . 24 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 13.1. Security Directive Registry . . . . . . . . . . . . . . . 24
11.1. Security Tag Registry . . . . . . . . . . . . . . . . . . 24 13.2. Initial Set of Security Directives . . . . . . . . . . . . 25
11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 25 13.3. POP3S Port Registration Update . . . . . . . . . . . . . . 27
11.3. POP3S Port Registration Update . . . . . . . . . . . . . 27 13.4. IMAPS Port Registration Update . . . . . . . . . . . . . . 28
11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 27 13.5. Submissions Port Registration . . . . . . . . . . . . . . 28
11.5. Submissions Port Registration . . . . . . . . . . . . . . 28 13.6. STS IMAP Capability . . . . . . . . . . . . . . . . . . . 29
11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 28 13.7. STS POP3 Capability . . . . . . . . . . . . . . . . . . . 29
11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 29 13.8. MSTS SMTP EHLO Keyword . . . . . . . . . . . . . . . . . . 30
11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 29 13.9. MAIL Parameters Additional-registered-clauses
11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . . 29 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 30
11.10. MAIL Parameters Additional-registered-clauses 14. Security Considerations . . . . . . . . . . . . . . . . . . . 30
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 30 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 15.1. Normative References . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 15.2. Informative References . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Design Considerations . . . . . . . . . . . . . . . . 34 Appendix A. Design Considerations . . . . . . . . . . . . . . . . 34
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
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/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409]
usually has Transport Layer Security (TLS) [RFC5246] support but usually has Transport Layer Security (TLS) [RFC5246] support but
often does not use it in a way that maximizes end-user often does not use it in a way that maximizes end-user
confidentiality. This specification proposes changes to email confidentiality. This specification proposes changes to email
software and deployments intended to increase the use of TLS and software and deployments intended to increase the use of TLS and
record when that use occurs. record when that use occurs. This adapts the strict transport
security (STS) model described in [RFC6797] to cover mail user agents
(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 confidentiality assurance level with each mail
account, and the default level requires use of TLS with account, and the default level requires use of TLS with
certificate validation for all TCP connections; 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. indicate that usage appropriately. The security upgrade model is
aligned with the HTTP STS specification [RFC6797].
This does not address use of TLS with SMTP for message relay (where This does not address use of TLS with SMTP for message relay (where
Message Submission [RFC6409] does not apply). Improved use of TLS Message Submission [RFC6409] does not apply). Improved use of TLS
with SMTP for message relay requires a different approach. One with SMTP for message relay requires a different approach. One
approach to address that topic is described in [RFC7672]. approach to address that topic is described in [RFC7672].
The recommendations in this memo do not replace the functionality of, The recommendations in this memo do not replace the functionality of,
and are not intended as a substitute for, end-to-end encryption of and are not intended as a substitute for, end-to-end encryption of
electronic mail. electronic mail.
skipping to change at page 6, line 17 skipping to change at page 6, line 21
A mail account has a high confidentiality assurance when the A mail account has a high confidentiality assurance 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 attempt to negotiate TLS via either Implicit
TLS Section 4 or STARTTLS. TLS Section 4 or STARTTLS.
o MUAs MUST implement [I-D.ietf-uta-email-tls-certs] and PKIX o MUAs MUST implement [RFC7817] and PKIX [RFC5280].
[RFC5280].
o MUAs MAY implement DANE [RFC6698]. o MUAs MAY implement DANE [RFC6698].
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
skipping to change at page 6, line 50 skipping to change at page 7, line 6
3.2. No Confidentiality Assurance 3.2. No Confidentiality Assurance
MUAs MAY implement a no confidentiality assurance level for accounts. MUAs MAY implement a no confidentiality assurance level for accounts.
At this level, the MUA MUST attempt to negotiate TLS, but MAY ignore At this level, the MUA MUST attempt to negotiate TLS, but MAY ignore
server certificate validation failures. MUAs MAY support use of server certificate validation failures. MUAs MAY support use of
connections without TLS, but if they do they SHOULD attempt TLS first connections without TLS, but if they do they SHOULD attempt TLS first
if available and MUST implement code to reconnect without TLS if TLS if available and MUST implement code to reconnect without TLS if TLS
negotiation fails for reasons other than server certificate validity. negotiation fails for reasons other than server certificate validity.
Note that if the TLS certificate is not successfully validated as Note that if the TLS certificate is not successfully validated as
described in Section 3.1 or a version of SSL/TLS prior to TLS 1.0 is described in Section 3.1 or a version of SSL/TLS prior to TLS 1.1 is
used, the client MUST NOT present a high confidentiality indication used, the client MUST NOT present a high confidentiality indication
for the account or connection. for the 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 more
confidentiality assurance levels are permitted. However, levels confidentiality assurance levels are permitted. However, levels
below "no confidentiality assurance" described in the previous below "no confidentiality assurance" described in the previous
section are discouraged and implementers are cautioned that end users section are discouraged and implementers are cautioned that end users
skipping to change at page 7, line 34 skipping to change at page 7, line 39
a separate port (referred to in this document as "Implicit TLS") has a separate port (referred to in this document as "Implicit TLS") has
been deployed more successfully. To increase use of TLS, this been deployed more successfully. To increase use of TLS, this
specification recommends use of implicit TLS by new POP, IMAP and specification recommends use of implicit TLS by new POP, IMAP and
SMTP Submission software. SMTP Submission software.
4.1. Implicit TLS for POP 4.1. Implicit TLS for POP
When a TCP connection is established for the "pop3s" service (default When a TCP connection is established for the "pop3s" service (default
port 995), a TLS handshake begins immediately. Clients MUST port 995), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in implement the certificate validation mechanism described in
[I-D.ietf-uta-email-tls-certs]. Once the TLS session is established, [RFC7817]. Once the TLS session is established, POP3 [RFC1939]
POP3 [RFC1939] protocol messages are exchanged as TLS application protocol messages are exchanged as TLS application data for the
data for the remainder of the TCP connection. After the server sends remainder of the TCP connection. After the server sends a +OK
a +OK greeting, the server and client MUST enter AUTHORIZATION state, greeting, the server and client MUST enter AUTHORIZATION state, even
even if client credentials were supplied during the TLS handshake. if client credentials were supplied during the TLS handshake.
See Section 9.1.1 for additional information on client certificate See Section 11.1.1 for additional information on client certificate
authentication. See Section 11.3 for port registration information. authentication. See Section 13.3 for port registration information.
4.2. Implicit TLS for IMAP 4.2. Implicit TLS for IMAP
When a TCP connection is established for the "imaps" service (default When a TCP connection is established for the "imaps" service (default
port 993), a TLS handshake begins immediately. Clients MUST port 993), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in [RFC3501] implement the certificate validation mechanism described in [RFC3501]
and SHOULD implement the certificate validation mechanism described and SHOULD implement the certificate validation mechanism described
in [I-D.ietf-uta-email-tls-certs]. Once the TLS session is in [RFC7817]. Once the TLS session is established, IMAP [RFC3501]
established, IMAP [RFC3501] protocol messages are exchanged as TLS protocol messages are exchanged as TLS application data for the
application data for the remainder of the TCP connection. If client remainder of the TCP connection. If client credentials were provided
credentials were provided during the TLS handshake that the server during the TLS handshake that the server finds acceptable, the server
finds acceptable, the server MAY issue a PREAUTH greeting in which MAY issue a PREAUTH greeting in which case both the server and client
case both the server and client enter AUTHENTICATED state. If the enter AUTHENTICATED state. If the server issues an OK greeting then
server issues an OK greeting then both server and client enter NOT both server and client enter NOT AUTHENTICATED state.
AUTHENTICATED state.
See Section 9.1.1 for additional information on client certificate See Section 11.1.1 for additional information on client certificate
authentication. See Section 11.4 for port registration information. authentication. See Section 13.4 for port registration information.
4.3. Implicit TLS for SMTP Submission 4.3. Implicit TLS for SMTP Submission
When a TCP connection is established for the "submissions" service When a TCP connection is established for the "submissions" service
(default port 465), a TLS handshake begins immediately. Clients MUST (default port 465), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in implement the certificate validation mechanism described in
[I-D.ietf-uta-email-tls-certs]. Once a TLS session is established, [RFC7817]. Once a TLS session is established, message submission
message submission protocol data [RFC6409] is exchanged as TLS protocol data [RFC6409] is exchanged as TLS application data for the
application data for the remainder of the TCP connection. (Note: the remainder of the TCP connection. (Note: the "submissions" service
"submissions" service name is defined in section 10.3 of this name is defined in section 10.3 of this document, and follows the
document, and follows the usual convention that the name of a service usual convention that the name of a service layered on top of
layered on top of Implicit TLS consists of the name of the service as Implicit TLS consists of the name of the service as used without TLS,
used without TLS, with an "s" appended.) with an "s" appended.)
The STARTTLS mechanism on port 587 is relatively widely deployed due The STARTTLS mechanism on port 587 is relatively widely deployed due
to the situation with port 465 (discussed in Section 11.5). This to the situation with port 465 (discussed in Section 13.5). This
differs from IMAP and POP services where implicit TLS is more widely differs from IMAP and POP services where implicit TLS is more widely
deployed on servers than STARTTLS. It is desirable to migrate core deployed on servers than STARTTLS. It is desirable to migrate core
protocols used by MUA software to implicit TLS over time for protocols used by MUA software to implicit TLS over time for
consistency as well as the additional reasons discussed in consistency as well as the additional reasons discussed in
Appendix A. However, to maximize use of encryption for submission it Appendix A. However, to maximize use of encryption for submission it
is desirable to support both mechanisms for Message Submission over is desirable to support both mechanisms for Message Submission over
TLS for a transition period of several years. As a result, clients TLS for a transition period of several years. As a result, clients
and servers SHOULD implement both STARTTLS on port 587 and implicit and servers SHOULD implement both STARTTLS on port 587 and implicit
TLS on port 465 for this transition period. Note that there is no TLS on port 465 for this transition period. Note that there is no
significant difference between the security properties of STARTTLS on significant difference between the security properties of STARTTLS on
port 587 and implicit TLS on port 465 if the implementations are port 587 and implicit TLS on port 465 if the implementations are
correct and both client and server are configured to require correct and both client and server are configured to require
successful negotiation of TLS prior to message submission (as successful negotiation of TLS prior to message submission (as
required in Section 9.1). required in Section 11.1).
Note that the submissions port provides access to a Mail Submission Note that the submissions port provides access to a Mail Submission
Agent (MSA) as defined in [RFC6409] so requirements and Agent (MSA) as defined in [RFC6409] so requirements and
recommendations for MSAs in that document apply to the submissions recommendations for MSAs in that document apply to the submissions
port, including the requirement to implement SMTP AUTH [RFC4954]. port, including the requirement to implement SMTP AUTH [RFC4954].
See Section 9.1.1 for additional information on client certificate See Section 11.1.1 for additional information on client certificate
authentication. See Section 11.5 for port registration information. authentication. See Section 13.5 for port registration information.
4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP
When a client or server wishes to close the connection, it SHOULD When a client or server wishes to close the connection, it SHOULD
initiate the exchange of TLS close alerts before TCP connection initiate the exchange of TLS close alerts before TCP connection
termination. The client MAY, after sending a TLS close alert, termination. The client MAY, after sending a TLS close alert,
gracefully close the TCP connection without waiting for a TLS gracefully close the TCP connection without waiting for a TLS
response from the server. response from the server.
5. Email Security Upgrading Using Security Latches 5. Email Security Upgrading Using Security Directives
Once an improved email security mechanism is deployed and ready for Once an improved email security mechanism is deployed and ready for
general use, it is desirable to continue using it for all future general use, it is desirable to continue using it for all future
email service. For example, TLS is widely deployed in email email service. For example, TLS is widely deployed in email
software, but use of TLS is often not required. At the time this is software, but use of TLS is often not required. At the time this is
written, deployed mail user agents (MUAs) [RFC5598] usually make a written, deployed mail user agents (MUAs) [RFC5598] usually make a
determination if TLS is available when an account is first configured determination if TLS is available when an account is first configured
and may require use of TLS with that account if and only if it was and may require use of TLS with that account if and only if it was
initially available. If the service provider makes TLS available initially available. If the service provider makes TLS available
after initial client configuration, many MUAs will not notice the after initial client configuration, many MUAs will not notice the
change. change.
Alternatively, a security feature may be purely opportunistic and Alternatively, a security feature may be purely opportunistic and
thus subject to downgrade attacks. For example, at the time this was thus subject to downgrade attacks. For example, at the time this was
written, most TLS stacks that support TLS 1.2 will use an older TLS written, most TLS stacks that support TLS 1.2 will use an older TLS
version if the peer does not support TLS 1.2 and some do so without version if the peer does not support TLS 1.2 and many do so without
alerting the client of the reduced security. Thus a variety of alerting the user of the reduced security. Thus a variety of active
active attacks could cause the loss of TLS 1.2 benefits. Only if attacks could cause the loss of TLS 1.2 benefits. Only if client
client policy is upgraded to require TLS 1.2 can the client prevent policy is upgraded to require TLS 1.2 can the client prevent all
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 latches", which This section describes a mechanism, called "security directives",
is designed to permit an MUA to recognize when a service provider has which is designed to permit an MUA to recognize when a service
committed to provide certain server security features, and that it's provider has committed to provide certain server security features,
safe for the client to change its configuration for that account to and that it's safe for the client to change its configuration for
require that such features be present in future sessions with that that account to require that such features be present in future
server. When an MUA implements both confidentiality assurance levels sessions with that server. When an MUA implements both
and security latches, then both the end-user and the service provider confidentiality assurance levels and security directives, then both
independently have the ability to improve the end-user's the end-user and the service provider independently have the ability
confidentiality. to improve the end-user's confidentiality.
Note that security latches are a mechanism similar to HTTP Strict A security directive has the following formal syntax:
Transport Security (HSTS) [RFC6797] but are extensible.
5.1. Email Security Tags directive = directive-name [ "=" directive-value ]
Each security latch is given a name known as an email security tag. directive-name = token
An email security tag is a short alphanumeric token that represents a
security facility that can be used by an IMAP, POP or SMTP Submission
session. When a server advertises a security tag it is making a
commitment to support that security facility indefinitely and
recommending that the client save that security tag with the account
configuration and require that security feature for future
connections to that server. When a security tag is saved by the
client in this way, it is then considered latched. For the "tls11"
and/or "tls12" tags, the client SHOULD refuse to connect to the
server unless the appropriate level of TLS is successfully
negotiated. The client SHOULD NOT latch tags unless they are
advertised by the server, TLS is active and the client successfully
authenticates the server with the TLS session. Once a security tag
is latched, all subsequent connections to that host require that
security feature. For this confidentiality protection to work as
desired clients MUST NOT offer a click-through-to-connect action when
unable to achieve connection security matching the latched security
tags.
An identifier for a security tag has the following formal syntax: directive-value = token
security-tag = ALPHA *63(ALPHA / DIGIT / "-" / "_") token = <As defined in RFC 7230>
5.2. Initial Set of Email Security Tags This is a subset of the syntax used by HSTS [RFC6797] as revised in
[RFC7230]; but simplified for use by protocols other than HTTP.
This section describes an initial set of email security tags. The 6. Server Strict Transport Security Policy
IANA Considerations Section 11 defines a registry so that more tags
can be defined in the future. The initial set of tags are defined in
Section 11.2 and include tls11, tls12, tls-cert and tls-dane-tlsa.
5.3. Server DEEP Status Servers supporting this extension MUST advertise an STS policy. This
includes a list of security directives the server administrator has
explicitly configured as recommended for use by clients (the list MAY
be empty). When a server advertises a security directive associated
with a security facility, it is making a commitment to support that
facility (or a revised version of that facility) indefinitely and
recommending that the client save that directive with the account
configuration and require that security facility for future
connections to that server.
Servers supporting this extension MUST advertise a DEEP status. This Server STS policy may also include a "sts-url" directive with a value
status includes a list of security-tags the server administrator has containing an https Uniform Resource Locator (URL) [RFC2818] that the
explicitly configured as recommended for use by end-users (the list client can save and subsequently resolve for the user in the event of
MAY be empty), an optional https Uniform Resource Locator (URL) a security connection problem. Server STS policy has the following
[RFC2818] that the client can save and subsequently resolve for the formal syntax:
user in the event of a security connection problem, and the DEEP
status can be extended by future updates to this specification. DEEP
status has the following formal syntax:
EXTCHAR = 0x20-21 / 0x23-2E / 0x30-3B / 0x3D-40 sts-policy = [directive *(";" [SP] directive)]
/ 0x5B-60 / 0x7B-7E
; printable characters excluding " \ < and ALPHA
deep-extend = EXTCHAR *(EXTCHAR / ALPHA / "<") Protocol extensions to advertise STS policy for email servers are
; clients MUST ignore, for future extensibility defined in Section 9.
deep-status = [deep-tag *(SP deep-tag)] The IANA Considerations Section 13 defines a registry so that more
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
tls-cert.
deep-tag = deep-https / security-tag / deep-extend 7. Client Storage of Email Security Directives
deep-https = "<" <URI from RFC 3986 with https scheme> ">" Before a client can consider storing any security directives, it MUST
verify that the connection to the server uses TLS, the server has
been authenticated, and any requirements for any previously saved
security directives are met. Then the client performs the following
steps for each security directive in the STS policy:
The syntax for a Uniform Resource Identifier (URI) is defined in 1. If the security directive name is not known to the client, skip
[RFC3986]. Protocol extensions to advertise DEEP status are defined to the next directive.
in Section 7.
If the client successfully negotiates TLS and authenticates the 2. If the security directive is already saved with the same value
server (e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with (or a value considered greater than the current value in the
channel bindings [RFC5802]), then the client SHOULD record the directive's definition), the client skips the security directive
server's DEEP status information in the account configuration with and moves on to the next one.
the server's hostname. Otherwise, the client SHOULD ignore the
server-provided DEEP status.
5.4. Email Security Tag Latch Failures 3. The client verifies the connection meets the requirements of the
security directive. If the connection does not, then the
directive will not be saved.
When a security tag latch has been set for connections from a client 4. If previous steps pass, the client SHOULD update the current
to a server and the property identified by that tag is no longer account configuration to save the security directive.
available, this results in a connection failure. An MUA SHOULD
inform the user of a potential threat to their confidentiality and Once a security directive is saved, all subsequent connections to
offer to resolve a previously-recorded DEEP status https URL if one that host require any associated security feature. For this
confidentiality protection to work as desired clients MUST NOT offer
a click-through-to-connect action when unable to achieve connection
security matching the saved security directives.
7.1. Security Directive Upgrade Example
Suppose a server advertises the "tls-version" directive name with
value "1.1". A client that successfully negotiates either TLS 1.1 or
TLS 1.2 SHOULD save this directive. The server may subsequently
change the value to "1.2". When a client with "1.1" saved value
connects and negotiates TLS 1.2, it will upgrade the saved directive
value to "1.2". However, a client that only supports TLS 1.1 will
continue to require use of TLS 1.1 and work with that server as long
as it permits TLS 1.1. This way individual clients can require the
newer/stronger protocol (e.g., TLS 1.2), while older clients can
continue to communicate securely (albeit potentially less so) using
the older protocol.
7.2. Security Policy Failures
When a security directive has been saved for connections from a
client to a server and the facility identified by that directive is
no longer available, this results in a connection failure. An MUA
SHOULD inform the user of a potential threat to their confidentiality
and offer to resolve a previously-recorded sts-url https URL if one
is available. MUAs are discouraged from offering a lightweight is available. MUAs are discouraged from offering a lightweight
option to reset or ignore latches as this defeats the benefit they option to reset or ignore directives as this defeats the benefit they
provide to end users. provide to end users.
6. Recording TLS Cipher Suite in Received Header 8. Recording TLS Cipher Suite in Received Header
The ESMTPS transmission type [RFC3848] provides trace information The ESMTPS transmission type [RFC3848] provides trace information
that can indicate TLS was used when transferring mail. However, TLS that can indicate TLS was used when transferring mail. However, TLS
usage by itself is not a guarantee of confidentiality or security. usage by itself is not a guarantee of confidentiality or security.
The TLS cipher suite provides additional information about the level The TLS cipher suite provides additional information about the level
of security made available for a connection. This defines a new SMTP of security made available for a connection. This defines a new SMTP
"tls" Received header additional-registered-clause that is used to "tls" Received header additional-registered-clause that is used to
record the TLS cipher suite that was negotiated for the connection. record the TLS cipher suite that was negotiated for the connection.
The value included in this additional clause SHOULD be the registered The value included in this additional clause SHOULD be the registered
cipher suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) cipher suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
skipping to change at page 12, line 17 skipping to change at page 12, line 30
tls-cipher-clause = CFWS "tls" FWS tls-cipher tls-cipher-clause = CFWS "tls" FWS tls-cipher
tls-cipher = tls-cipher-suite-name / tls-cipher-suite-hex tls-cipher = tls-cipher-suite-name / tls-cipher-suite-hex
tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_") tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_")
; as registered in IANA cipher suite registry ; as registered in IANA cipher suite registry
tls-cipher-hex = "0x" 4HEXDIG tls-cipher-hex = "0x" 4HEXDIG
7. Extensions for DEEP Status and Reporting 9. Extensions for STS Policy and Reporting
This memo defines optional mechanisms for use by MUAs to communicate This memo defines optional mechanisms for use by MUAs to communicate
DEEP status to servers and for servers to advertise available saved STS policy to servers and for servers to advertise policy. One
latches. One purpose of such mechanisms is to permit servers to purpose of such mechanisms is to permit servers to determine which
determine which and how many clients have latched security and how many clients have saved security directives, and thus, to
facilities, and thus, to permit operators to be aware of potential permit operators to be aware of potential impact to their users
impact to their users should support for such facilities be changed. should support for such facilities be changed. For IMAP, the
For IMAP, the existing ID command is extended to provide this existing ID command is extended to provide this capability. For SMTP
capability. For SMTP Submission, a new CLIENT command is defined. Submission, a new CLIENT command is defined. No similar mechanism is
No similar mechanism is defined for POP in this version of the memo defined for POP in this version of the memo to keep POP simpler, but
to keep POP simpler, but one may be added in the future if deemed one may be added in the future if deemed necessary.
necessary.
In addition, for each of IMAP, POP, and SMTP, a new DEEP capability In addition, for each of IMAP, POP, and SMTP, a new STS capability is
is defined so the client can access the server's DEEP status. defined so the client can access the server's STS policy.
7.1. IMAP DEEP Extension 9.1. IMAP STS Extension
When an IMAP server advertises the DEEP capability, that indicates When an IMAP server advertises the STS capability, that indicates the
the IMAP server implements IMAP4 ID [RFC2971] with additional field IMAP server implements IMAP4 ID [RFC2971] with additional field
values defined here. This is grouped with the ID command because values defined here. This is grouped with the ID command because
that is the existing IMAP mechanism for clients to report data for that is the existing IMAP mechanism for clients to report data for
server logging, and provides a way for the server to report the DEEP server logging, and provides a way for the server to report the STS
status. policy.
deep From server to client, the argument to this ID field is the sts From server to client, the argument to this ID field is the
server DEEP status. Servers MUST provide this information in server STS policy. Servers MUST provide this information in
response to an ID command. response to an ID command.
latch From client to server, this is a space-separated list of saved From client to server, this is a list of security directives
security tags the client has latched for this server. Servers MAY the client has saved for this server (the client MAY omit the
record this information so administrators know the expected latch- value for the sts-url directive in this context). Servers MAY
related security properties of the client and can thus act to record this information so administrators know the expected
avoid security latch failures (e.g., by renewing server security properties of the client and can thus act to avoid
certificates on time, etc). security policy failures (e.g., by renewing server certificates on
time, etc).
latch-fail From client to server, a space-separated list including policy-fail From client to server, a list including one or more
one or more security tag the client has latched that the client security directives the client has saved that the client was
was unable to achieve. This allows clients to report errors to unable to achieve. This allows clients to report errors to the
the server prior to terminating the connection to the server in server prior to terminating the connection in the event an
the event an acceptable security level is unavailable. acceptable security level is unavailable.
security-tags From client to server, this is a space-separated list directives From client to server, this is a list of security
of security tags the client supports that are not latched. directive names the client supports that are not saved.
tls Server-side IMAP proxies that accept TLS connections from tls Server-side IMAP proxies that accept TLS connections from
clients and connect in-the-clear over a fully private secure clients and connect in-the-clear over a fully private secure
network to the server SHOULD use this field to report the tls- network to the server SHOULD use this field to report the tls-
cipher (syntax as defined in Section 6) to the server. cipher (syntax as defined in Section 8) to the server.
IMAP clients SHOULD use the IMAP ID command to report latch failures IMAP clients SHOULD use the IMAP ID command to report policy failures
and determine the server DEEP status. Clients MAY use the ID command and determine the server STS policy. Clients MAY use the ID command
to report other latch or security tag information. IMAP servers MUST to report other security directive information. IMAP servers MUST
implement the ID command at least to report DEEP status to clients. implement the ID command at least to report STS policy to clients.
<client connected to port 993 and negotiated TLS successfully> <client connected to port 993 and negotiated TLS successfully>
S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN S: * OK [CAPABILITY IMAP4rev1 STS ID AUTH=PLAIN
AUTH=SCRAM-SHA-1] hello AUTH=SCRAM-SHA-1] hello
C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch" C: a001 ID ("name" "Demo Mail" "version" "1.5" "saved"
"tls11 tls-cert" "security-tags" "tls12") "tls-version=1.1; tls-cert"
S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" "directives" "tls-version=1.2")
"<https://www.example.com/security-support.html>") S: * ID ("name" "Demo Server" "version" "1.7" "sts-policy"
"tls-version=1.1; tls-cert;
sts-url=https://www.example.com/security-support.html")
S: a001 OK ID completed S: a001 OK ID completed
Example 1 Example 1
This example shows a client that successfully negotiated TLS version This example shows a client that successfully negotiated TLS version
1.0 or later and verified the server's certificate as required by 1.1 or later and verified the server's certificate as required by
IMAP. The client supports TLS 1.2. However, even if the client IMAP. Even if the client successfully validates the server
successfully negotiated TLS 1.2, it will not latch that security tag certificate, it will not require tls-version 1.2 in the future as the
automatically because the server did not advertise that tag. If the server does not advertise that version as policy. The client has not
client successfully validated the server certificate, it will latch yet saved an STS URL, but if the client successfully validated the
the provided URL. server certificate, it will save the provided URL.
<client connected to port 993 and negotiated TLS successfully> <client connected to port 993 and negotiated TLS successfully>
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" "latch-failure" C: a001 ID ("name" "Demo Mail" "version" "1.5" "policy-failure"
"tls-cert") "tls-cert=pkix")
S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" S: * ID ("name" "Demo Server" "version" "1.7" "sts-policy"
"tls11 <https://www.example.com/security-support.html>") "tls-version=1.1;
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 latch-failure informs the verify the server's certificate. The policy-failure informs the
server of this problem, at which point the client can disconnect. If server of this problem, at which point the client can disconnect. If
the client had previously latched a URI for security problems from the client had previously latched a URI for security problems from
this server, it could offer to resolve that URI. However, the deep- this server, it could offer to resolve that URI. However, the sts-
status in this exchange is ignored due to the latch failure. policy in this exchange is ignored due to the latch failure.
<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" "latch" C: a001 ID ("name" "Demo Mail" "version" "1.5" "saved"
"tls11 tls-cert" "security-tags" "tls12" "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" "deep-status" S: * ID ("name" "Demo Server" "version" "1.7" "sts-policy"
"tls11 tls-cert <https://www.example.com/support.html>") "tls-version=1.1; tls-cert=pkix;
sts-url=https://www.example.com/support.html")
S: a001 OK ID completed S: a001 OK ID completed
Example 3 Example 3
This example shows the connection from an IMAP proxy to a back-end This example shows the connection from an IMAP proxy to a back-end
server. The client connected to the proxy and sent the ID command 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.
7.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.
<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: DEEP tls11 tls12 <https://www.example.com/security-support.html> S: STS tls-version=1.2
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 latch any or all of the DEEP status. If the client client can save any or all of the STS policy. If the client connects
connects to this same server later and has a security failure, the to this same server later and has a security failure, the client can
client can direct the user's browser to the previously-latched URI direct the user's browser to the previously-saved URL where the
where the service provider may provide advice to the end user. service provider can provide advice to the end user.
7.3. SMTP DEEP Extension 9.3. SMTP MSTS Extension
SMTP Submission servers supporting this specification MUST implement SMTP Submission servers supporting this specification MUST implement
the DEEP SMTP extension. The name of this extension is DEEP. The the MSTS SMTP extension. The name of this extension is MSTS. The
EHLO keyword value is DEEP and the deep-status 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 / latch-fail deep-parameter = name / version / latch / policy-fail
/ security-tags / tls / future-extension / directives / tls / future-extension
name = "name=" esmtp-value name = "name" SP esmtp-value
version = "version=" esmtp-value version = "version" SP esmtp-value
latch = "latch=" security-tag *("," security-tag) saved = "saved" SP directive-list
latch-fail = "latch-fail=" security-tag policy-fail = "policy-fail" SP directive-list
*("," security-tag)
security-tags = "security-tags=" security-tag directive-list = DQUOTE [directive
*("," security-tag) *(";" [SP] directive)] DQUOTE
tls = "tls=" tls-cipher directives = "directives" SP directive-list
future-extension = esmtp-param tls = "tls" SP tls-cipher
esmtp-param = <as defined in RFC 5321> future-extension = Atom SP String
esmtp-value = <as defined in RFC 5321> Atom = <as defined in RFC 5321>
String = <as defined in RFC 5321>
The CLIENT command parameters listed here have the same meaning as The CLIENT command parameters listed here have the same meaning as
the parameters used in the IMAP DEEP extension (Section 7.1). The the parameters used in the IMAP STS extension (Section 9.1). The
server responds to the CLIENT command with a "250" if the command has server responds to the CLIENT command with a "250" if the command has
correct syntax and a "501" if the command has incorrect syntax. correct syntax and a "501" if the command has incorrect syntax.
<client connected to port 465 and negotiated TLS successfully> <client connected to port 465 and negotiated TLS successfully>
S: 220 example.com Demo SMTP Submission Server S: 220 example.com Demo SMTP Submission Server
C: EHLO client.example.com C: EHLO client.example.com
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-DEEP tls12 tls-cert <https://www.example.com/status.html> S: 250-MSTS tls-version=1.2; tls-cert;
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 latch=tls11,tls-cert C: CLIENT name demo_submit version 1.5 saved "tls-version=1.1;
security-tags=tls12 tls-cert=pkix" directives "tls-version=1.2"
S: 250 OK S: 250 OK
Example 5 Example 5
7.4. SMTP Error Extension 10. Account Setup Considerations
Although this document focuses on SMTP Submission, it is possible to
use security latches for SMTP transport as well. When MTA transport
fails due to a security latch, the MTA MUST use the SMTP enhanced
status code X.7.TBD (RFC Editor note: update this TBD). The SMTP
notary response [RFC3464] for a security latch failure MUST include
an additional "SMTP-Security-Latch" recipient-specific header field
that includes a space-delimited list including one or more security
latch that failed. The ABNF for this new field follows:
CFWS = <defined in RFC 5322>
FWS = <defined in RFC 5322>
smtp-security-latch = "SMTP-Security-Latch:" CFWS
security-tag *(FWS security-tag)
8. Account Setup Considerations
8.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 high confidentiality assurance
level, unless the user has explicitly requested reduced level, unless the user has explicitly requested reduced
confidentiality. This will have the effect of causing the MUA to confidentiality. This will have the effect of causing the MUA to
skipping to change at page 18, line 22 skipping to change at page 18, line 5
Similarly, an MUA MUST NOT consult SRV records to determine which Similarly, an MUA MUST NOT consult SRV records to determine which
servers to use on every connection attempt, unless those SRV records servers to use on every connection attempt, unless those SRV records
are signed by DNSSEC and have a valid signature. However, an MUA MAY are signed by DNSSEC and have a valid signature. However, an MUA MAY
consult SRV records from time to time to determine if an MSP's server consult SRV records from time to time to determine if an MSP's server
configuration has changed, and alert the user if it appears that this configuration has changed, and alert the user if it appears that this
has happened. This can also serve as a means to encourage users to has happened. This can also serve as a means to encourage users to
upgrade their configurations to require TLS if and when their MSPs upgrade their configurations to require TLS if and when their MSPs
support it. support it.
8.2. Certificate Pinning 10.2. Certificate Pinning
During account setup, the MUA will identify servers that provide During account setup, the MUA will identify servers that provide
account services such as mail access and mail submission (the account services such as mail access and mail submission (the
previous section describes one way to do this). The certificates for previous section describes one way to do this). The certificates for
these servers are verified using the rules described in these servers are verified using the rules described in [RFC7817] and
[I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. In the event the PKIX [RFC5280]. In the event the certificate does not validate due
certificate does not validate due to an expired certificate, lack of to an expired certificate, lack of appropriate chain of trust or lack
appropriate chain of trust or lack of identifier match, the MUA MAY of identifier match, the MUA MAY create a persistent binding between
create a persistent binding between that certificate and the saved that certificate and the saved host name for the server. This is
host name for the server. This is called certificate pinning. called certificate pinning. Certificate pinning is only appropriate
Certificate pinning is only appropriate during account setup and MUST during account setup and MUST NOT be offered in response to a failed
NOT be offered in response to a failed certificate validation for an certificate validation for an existing account. An MUA that allows
existing account. An MUA that allows certificate pinning MUST NOT certificate pinning MUST NOT allow a certificate pinned for one
allow a certificate pinned for one account to validate connections account to validate connections for other accounts.
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 provide a high confidentiality assurance and an MUA MUST NOT
indicate a high level for an account or connection using a pinned indicate a high level for an account or connection using a pinned
certificate. Additional advice on certificate pinning is present in certificate. Additional advice on certificate pinning is present in
[RFC6125]. [RFC6125].
9. 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.
9.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 be configurable to support implicit TLS
using the TLS 1.2 protocol or later [RFC5246]. 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
second paragraph of section 11.1 and replace it with the text from second paragraph of section 11.1 and replace it with the text from
the first three bullet items in this list. See Appendix B of the first three bullet items in this list. See Appendix B of
[I-D.ietf-uta-email-tls-certs] to see additional modifications to [RFC7817] to see additional modifications to IMAP certificate
IMAP certificate validation rules. validation rules.
o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is
modified to revoke section 2.1 and replace it with the text from modified to revoke section 2.1 and replace it with the text from
the first three bullet items in this list. See Appendix B of the first three bullet items in this list. See Appendix B of
[I-D.ietf-uta-email-tls-certs] to see additional modifications to [RFC7817] to see additional modifications to RFC 2595 certificate
RFC 2595 certificate validation rules. validation rules.
o The standard for Message Submission [RFC6409] is updated to add o The standard for Message Submission [RFC6409] is updated to add
the first three bullet items above to section 4.3 as well as to the first three bullet items above to section 4.3 as well as to
require implementation of the TLS server identity check as require implementation of the TLS server identity check as
described in [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. described in [RFC7817] and PKIX [RFC5280].
9.1.1. Client Certificate Authentication 11.1.1. Client Certificate Authentication
MUAs and mail servers MAY implement client certificate authentication MUAs and mail servers MAY implement client certificate authentication
on the implicit TLS port. Servers MUST NOT request a client on the implicit TLS port. Servers MUST NOT request a client
certificate during the TLS handshake unless the server is configured certificate during the TLS handshake unless the server is configured
to accept some client certificates as sufficient for authentication to accept some client certificates as sufficient for authentication
and the server has the ability to determine a mail server and the server has the ability to determine a mail server
authorization identity matching such certificates. How to make this authorization identity matching such certificates. How to make this
determination is presently implementation specific. Clients MUST NOT determination is presently implementation specific. Clients MUST NOT
provide a client certificate during the TLS handshake unless the provide a client certificate during the TLS handshake unless the
server requests one and the client has determined the certificate can server requests one and the client has determined the certificate can
skipping to change at page 20, line 17 skipping to change at page 19, line 49
with that server. How to make this determination is presently with that server. How to make this determination is presently
implementation specific. If the server accepts the client's implementation specific. If the server accepts the client's
certificate as sufficient for authorization, it MUST enable the SASL certificate as sufficient for authorization, it MUST enable the SASL
EXTERNAL [RFC4422] mechanism. An IMAPS server MAY issue a PREAUTH EXTERNAL [RFC4422] mechanism. An IMAPS server MAY issue a PREAUTH
greeting instead of enabling SASL EXTERNAL. A client supporting greeting instead of enabling SASL EXTERNAL. A client supporting
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]).
9.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 7 o Servers MUST implement the DEEP extension 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 if it is unlikely to succeed
based on server configuration (e.g., there is no server 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 6. 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.
9.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 to use of
SMTP servers (e.g., port 25) for mail submission. 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 expected level of confidentiality based on appropriate security
inputs such as which security latches are pre-set, the number of inputs such as which security directives are pre-set, the number
trust anchors, certificate validity, use of an extended validation of trust anchors, certificate validity, use of an extended
certificate, TLS version supported, and TLS cipher suites validation certificate, TLS version supported, and TLS cipher
supported by both server and client. This indication SHOULD also suites supported by both server and client. This indication
be present when editing or viewing account configuration. SHOULD also be present when editing or viewing account
configuration.
o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes
available for a protocol and set the tls11 latch if the server available for a protocol and set the tls-version=1.1 directive if
advertises the tls11 security tag after a successful TLS the server advertises the tls-version=1.1 security policy after a
negotiation. successful TLS negotiation.
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 "tls12" security latch (the TLS library o MUAs SHOULD implement the "tls-version=1.2" security directive
has to provide an API that controls permissible TLS versions and (the TLS library has to provide an API that controls permissible
communicates the negotiated TLS protocol version to the TLS versions and communicates the negotiated TLS protocol version
application for this to be possible). to the application for this to be possible).
o See Section 3 for additional requirements. o See Section 3 for additional requirements.
9.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.
9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services 11.5. DEEP 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 do not impact DEEP. However, some services use
an SMTP relay proxy that intercepts mail at the application layer to an SMTP relay proxy that intercepts mail at the application layer to
perform a scan and proxy or forward to another MTA. Deploying AVAS perform a scan and proxy or forward to another MTA. Deploying AVAS
services in this way can cause many problems [RFC2979] including services in this way can cause many problems [RFC2979] including
direct interference with DEEP and confidentiality or security direct interference with DEEP and confidentiality or security
reduction. An AVAS product or service is considered DEEP compliant reduction. An AVAS product or service is considered DEEP compliant
if all IMAP, POP and SMTP-related software it includes is DEEP if all IMAP, POP and SMTP-related software it includes is DEEP
compliant and it advertises and supports all security latches that compliant and it advertises and supports all security directives that
the actual servers advertise. the actual 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 DEEP high confidentiality assurance
can prevent a man-in-the-middle from introducing spam or virus can prevent a man-in-the-middle from introducing spam or virus
content between the MUA and Submission server, it does not prevent content between the MUA and Submission server, it does not prevent
other forms of client or account compromise so use of AVAS services other forms of client or account compromise so use of AVAS services
for submitted email remains necessary. for submitted email remains necessary.
10. 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.
10.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
to this specification. to this specification.
10.2. MSPs MUST provide Submission Servers 12.2. MSPs MUST provide Submission Servers
This document updates the advice in [RFC5068] by making Implicit TLS This document updates the advice in [RFC5068] by making Implicit TLS
on port 465 the preferred submission port. on port 465 the preferred submission port.
Mail Service Providers that accept mail submissions from end-users Mail Service Providers that accept mail submissions from end-users
using the Internet Protocol MUST provide one or more SMTP Submission using the Internet Protocol MUST provide one or more SMTP Submission
services, separate from the SMTP MTA services used to process services, separate from the SMTP MTA services used to process
incoming mail. Those submission services MUST be configured to incoming mail. Those submission services MUST be configured to
support Implicit TLS on port 465 and SHOULD support STARTTLS if port support Implicit TLS on port 465 and SHOULD support STARTTLS if port
587 is used. 587 is used.
skipping to change at page 22, line 47 skipping to change at page 22, line 33
designated SMTP servers to facilitate compatibility with legacy MUAs. designated SMTP servers to facilitate compatibility with legacy MUAs.
Discussion: SMTP servers used to accept incoming mail or to relay Discussion: SMTP servers used to accept incoming mail or to relay
mail are expected to accept mail in cleartext. This is incompatible mail are expected to accept mail in cleartext. This is incompatible
with the purpose of this memo which is to encourage encryption of with the purpose of this memo which is to encourage encryption of
traffic between mail servers. There is no such requirement for mail traffic between mail servers. There is no such requirement for mail
submission servers to accept mail in cleartext or without submission servers to accept mail in cleartext or without
authentication. For other reasons, use of separate SMTP submission authentication. For other reasons, use of separate SMTP submission
servers has been best practice for many years. servers has been best practice for many years.
10.3. TLS Server Certificate Requirements 12.3. TLS Server Certificate Requirements
MSPs MUST maintain valid server certificates for all servers. See MSPs MUST maintain valid server certificates for all servers. See
[I-D.ietf-uta-email-tls-certs] for the recommendations and [RFC7817] for the recommendations and requirements necessary to
requirements necessary to achieve this. achieve this.
If a protocol server provides service for more than one mail domain, If a protocol server provides service for more than one mail domain,
it MAY use a separate IP address for each domain and/or a server it MAY use a separate IP address for each domain and/or a server
certificate that advertises multiple domains. This will generally be certificate that advertises multiple domains. This will generally be
necessary unless and until it is acceptable to impose the constraint necessary unless and until it is acceptable to impose the constraint
that the server and all clients support the Server Name Indication that the server and all clients support the Server Name Indication
extension to TLS [RFC6066]. For more discussion of this problem, see extension to TLS [RFC6066]. For more discussion of this problem, see
section 5.1 of [I-D.ietf-uta-email-tls-certs]. section 5.1 of [RFC7817].
10.4. Recommended DNS records for mail protocol servers 12.4. Recommended DNS records for mail protocol servers
This section discusses not only the DNS records that are recommended, This section discusses not only the DNS records that are recommended,
but also implications of DNS records for server configuration and TLS but also implications of DNS records for server configuration and TLS
server certificates. server certificates.
10.4.1. MX records 12.4.1. MX records
It is recommended that MSPs advertise MX records for handling of It is recommended that MSPs advertise MX records for handling of
inbound mail (instead of relying entirely on A or AAAA records), and inbound mail (instead of relying entirely on A or AAAA records), and
that those MX records be signed using DNSSEC. This is mentioned here that those MX records be signed using DNSSEC. This is mentioned here
only for completeness, as handling of inbound mail is out of scope only for completeness, as handling of inbound mail is out of scope
for this document. for this document.
10.4.2. SRV records 12.4.2. SRV records
MSPs SHOULD advertise SRV records to aid MUAs in determination of MSPs SHOULD advertise SRV records to aid MUAs in determination of
proper configuration of servers, per the instructions in [RFC6186]. proper configuration of servers, per the instructions in [RFC6186].
MSPs SHOULD advertise servers that support Implicit TLS in preference MSPs SHOULD advertise servers that support Implicit TLS in preference
to those which support cleartext and/or STARTTLS operation. to those which support cleartext and/or STARTTLS operation.
10.4.3. DNSSEC 12.4.3. DNSSEC
All DNS records advertised by an MSP as a means of aiding clients in All DNS records advertised by an MSP as a means of aiding clients in
communicating with the MSP's servers, SHOULD be signed using DNSSEC. communicating with the MSP's servers, SHOULD be signed using DNSSEC.
10.4.4. TLSA records 12.4.4. TLSA records
MSPs SHOULD advertise TLSA records to provide an additional trust MSPs SHOULD advertise TLSA records to provide an additional trust
anchor for public keys used in TLS server certificates. However, anchor for public keys used in TLS server certificates. However,
TLSA records MUST NOT be advertised unless they are signed using TLSA records MUST NOT be advertised unless they are signed using
DNSSEC. DNSSEC.
10.5. MSP Server Monitoring 12.5. MSP Server Monitoring
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.
10.6. Advertisement of DEEP status 12.6. Advertisement of DEEP status
MSPs SHOULD advertise a DEEP status that includes tls11, tls-cert and MSPs SHOULD advertise a DEEP status that includes tls11, tls-cert and
an HTTPS URL that can be used to inform clients of service outages or an HTTPS URL that can be used to inform clients of service outages or
problems impacting client confidentiality. Note that advertising problems impacting client confidentiality. Note that advertising
tls-cert is a commitment to maintain and renew server certificates. tls-cert is a commitment to maintain and renew server certificates.
10.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.
10.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
and mail submission services, including SMTP-based spam/virus and mail submission services, including SMTP-based spam/virus
filters, it is generally necessary to support the same and/or a newer filters, it is generally necessary to support the same and/or a newer
version of TLS and the same security tags that were previously version of TLS and the same security directives that were previously
advertised. advertised.
11. IANA Considerations 13. IANA Considerations
11.1. Security Tag Registry 13.1. Security Directive Registry
IANA shall create (has created) the registry "Email Security Tags". IANA shall create (has created) the registry "STS Security
This registry is a single table and will use an expert review process Directives". This registry is a single table and will use an expert
[RFC5226]. Each registration will contain the following fields: review process [RFC5226]. Each registration will contain the
following fields:
Name: The name of the security tag. This follows the security-tag Name: The name of the security directive. This follows the
ABNF. directive-name ABNF.
Description: This describes the meaning of the security tag and the Value: The permitted values of the security directive. This should
conditions under which the tag is latched. also explain if the value is optional or mandatory and what to do
if the value is not recognized.
Description: This describes the meaning of the security directive
and the conditions under which the directive is saved.
Scope: The protocols to which this security directive applies.
Presently this may be MSTS (for MUA STS), HSTS (for HTTP STS), or
ALL.
Intended Usage: One of COMMON, LIMITED USE or OBSOLETE. Intended Usage: One of COMMON, LIMITED USE or OBSOLETE.
Reference: Optional reference to specification. Reference: Optional reference to specification.
Submitter: The identify of the submitter or submitters. Submitter: The identify of the submitter or submitters.
Change Controller: The identity of the change controller for the Change Controller: The identity of the change controller for the
registration. This will be "IESG" in case of registrations in registration. This will be "IESG" in case of registrations in
IETF-produced documents. IETF-produced documents.
The expert reviewer will verify the tag name follows the ABNF, and The expert reviewer will verify the directive name follows the ABNF,
that the description field is clear, unambiguous, does not overlap and that the value and description fields are clear, unambiguous, do
existing deployed technology, does not create security problems and not overlap existing deployed technology, do not create security
appropriately considers interoperability issues. Email security tags problems and appropriately considers interoperability issues. Email
intended for LIMITED USE have a lower review bar (interoperability security directives intended for LIMITED USE have a lower review bar
and overlap issues are less of a concern). The reviewer may approve (interoperability and overlap issues are less of a concern). The
a registration, reject for a stated reason or recommend the proposal reviewer may approve a registration, reject for a stated reason or
have standards track review due to importance or difficult recommend the proposal have standards track review due to importance
subtleties. or difficult subtleties.
Standards-track registrations may be updated if the relevant Standards-track registrations may be updated if the relevant
standards are updated as a consequence of that action. Non- standards are updated as a consequence of that action. Non-
standards-track entries may be updated by the listed change standards-track entries may be updated by the listed change
controller. The entry's name and submitter may not be changed. In controller. The entry's name and submitter may not be changed. In
exceptional cases, any aspect of any registered entity may be updated exceptional cases, any aspect of any registered entity may be updated
at the direction of the IESG (for example, to correct a conflict). at the direction of the IESG (for example, to correct a conflict).
11.2. Initial Set of Security Tags 13.2. Initial Set of Security Directives
This document defines four initial security tags for the security tag This document defines three initial security directives for the
registry as follows: registry as follows, and registers the two additional directives
specified in [RFC6797].
Name: tls11 Name: tls-version
Description: This indicates TLS version 1.1 [RFC4346] or later was Value: Mandatory; 1.1 refers to [RFC4346] or later and 1.2 refers to
negotiated successfully including negotiation of a strong [RFC5246] or later. Future versions may be added; this is ignored
encryption layer with a symmetric key of at least 128 bits. This if the version is unrecognized.
tag indicates the server certificate was valid but does not
indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE Description: This directive indicates that the TLS version
[RFC6698]). This tag is latched if the client sees this tag in negotiated must be the specified version or later. In the event
the advertised server DEEP status provided after successfully this directive is saved and only an older TLS version is
negotiating TLS version 1.0 or later. available, that results in STS policy failure.
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: tls12 Value: Optional; pkix refers to PKIX certificate validation, dane
refers to DANE certificate validation, any refers to any
validation mechanism the client considers acceptable. If no value
is provided, "any" is assumed.
Description: This indicates TLS version 1.2 [RFC5246] or later was Description: This directive indicates that TLS was successfully
negotiated successfully including negotiation of a strong negotiated and the server certificate was successfully verified by
encryption layer with a symmetric key of at least 128 bits. This the client using PKIX [RFC5280] or DANE [RFC6698] and the server
tag indicates the server certificate was valid but does not certificate identity was verified using the algorithm appropriate
indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE for the protocol (see Section 4). This directive is saved if the
[RFC6698]). This tag is latched if the client sees this tag in client sees this in the advertised server STS policy after
the advertised server DEEP status provided after successfully successfully negotiating TLS and verifying the certificate and
negotiating TLS version 1.2 or later. server identity. For the HSTS protocol, this directive (with the
"any" value) is implied by the presence of the Strict-Transport-
Security header, as a result it is never specified in that
protocol.
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: sts-url
Description: This tag indicates that TLS was successfully negotiated Value: Mandatory for server-policy, optional for client reporting.
and the server certificate was successfully verified by the client The value is an https URL.
using PKIX [RFC5280] and the server certificate identity was
verified using the algorithm appropriate for the protocol (see Description: This directive indicates that the client SHOULD resolve
Section 4). This tag is latched if the client sees this tag in (with appropriate certificate validation) and display the URL in
the advertised server DEEP status after successfully negotiating the event of a policy failure.
TLS and verifying the certificate and server identity.
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
Name: max-age
Value: see [RFC6797].
Description: see [RFC6797].
Scope: HSTS only
Intended Usage: COMMON
Reference: [RFC6797]
Submitter: Authors of this document
Change Controller: IESG Change Controller: IESG
Name: tls-dane-tlsa Name: includeSubDomains
Description: This tag indicates that TLS was successfully negotiated Value: None
and the server certificate was successfully verified by the client
using the procedures described in [RFC6698] and the server Description: see [RFC6797].
certificate identity was verified using the algorithm appropriate
for the protocol (see Section 4). This tag is latched if the Scope: HSTS only
client sees this tag in the advertised server DEEP status after
successfully negotiating TLS and verifying the certificate and
server identity.
Intended Usage: COMMON Intended Usage: COMMON
Reference: RFC XXXX (this document once published) Reference: [RFC6797]
Submitter: Authors of this document Submitter: Authors of this document
Change Controller: IESG Change Controller: IESG
11.3. POP3S Port Registration Update 13.3. POP3S 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
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)
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)
11.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)
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)
11.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)
skipping to change at page 28, line 46 skipping to change at page 29, line 21
service, email software will either continue with unregistered use of service, email software will either continue with unregistered use of
port 465 (leaving the port registry inaccurate relative to de-facto port 465 (leaving the port registry inaccurate relative to de-facto
practice and wasting a well-known port), or confusion between the de- practice and wasting a well-known port), or confusion between the de-
facto and registered ports will cause harmful interoperability facto and registered ports will cause harmful interoperability
problems that will deter use of TLS for message submission. The problems that will deter use of TLS for message submission. The
authors believe both of these outcomes are less desirable than a wart authors believe both of these outcomes are less desirable than a wart
in the registry documenting real-world usage of a port for two in the registry documenting real-world usage of a port for two
purposes. Although STARTTLS-on-port-587 has deployed, it has not purposes. Although STARTTLS-on-port-587 has deployed, it has not
replaced deployed use of implicit TLS submission on port 465. replaced deployed use of implicit TLS submission on port 465.
11.6. DEEP IMAP Capability 13.6. STS IMAP Capability
This document adds the DEEP capability to the IMAP capabilities This document adds the STS capability to the IMAP capabilities
registry. This is described in Section 7.1. registry. This is described in Section 9.1.
11.7. DEEP POP3 Capability 13.7. STS POP3 Capability
This document adds the DEEP capability to the POP3 capabilities This document adds the STS capability to the POP3 capabilities
registry. registry.
CAPA Tag: DEEP CAPA Tag: STS
Arguments: deep-status Arguments: sts-policy
Added Commands: none Added Commands: none
Standard Commands affected: none Standard Commands affected: none
Announced status / possible differences: both / may change after Announced status / possible differences: both / may change after
STLS STLS
Commands Valid in States: N/A Commands Valid in States: N/A
Specification Reference: This document Specification Reference: This document
Discussion: See Section 7.2. Discussion: See Section 9.2.
11.8. DEEP SMTP EHLO Keyword
This document adds the DEEP EHLO Keyword to the SMTP Service
Extension registry. This is described in Section 7.3.
11.9. SMTP Enhanced Status Code
This document adds the following entry to the "SMTP Enhanced Status
Codes" registry created by [RFC5248].
Code: X.7.TBD (IANA, please assign the next available number)
Sample Text: Message Transport Failed due to missing required
security.
Associated Basic Status Code: 450, 454, 550, 554
Description This code indicates an SMTP server was unable to forward
a message to the next host necessary for delivery because it
required a higher level of transport security or confidentiality
than was available. The temporary form of this error is preferred
in case the problem is caused by a temporary administrative error
such as an expired server certificate.
Reference This document
Submitter C. Newman 13.8. MSTS SMTP EHLO Keyword
Change Controller IESG This document adds the MSTS EHLO Keyword to the SMTP Service
Extension registry. This is described in Section 9.3.
11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 13.9. MAIL Parameters Additional-registered-clauses Sub-Registry
This document adds the following entry to the "Additional-registered- This document adds the following entry to the "Additional-registered-
clauses" sub-registry of the "MAIL Parameters" registry, created by clauses" sub-registry of the "MAIL Parameters" registry, created by
[RFC5321]: [RFC5321]:
Clause Name: tls Clause Name: tls
Description: Indicates the TLS cipher suite used for a transport Description: Indicates the TLS cipher suite used for a transport
connection. connection.
Syntax Summary: See tls-cipher ABNF Section 6 Syntax Summary: See tls-cipher ABNF Section 8
Reference: This document. Reference: This document.
12. Security Considerations 14. Security Considerations
This entire document is about security considerations. In general, This entire document is about security considerations. In general,
this is targeted to improve mail confidentiality and to mitigate this is targeted to improve mail confidentiality and to mitigate
threats external to the email system such as network-level snooping threats external to the email system such as network-level snooping
or interception; this is not intended to mitigate active attackers or interception; this is not intended to mitigate active attackers
who have compromised service provider systems. who have compromised service provider systems.
It could be argued that sharing the name and version of the client It could be argued that sharing the name and version of the client
software with the server has privacy implications. Although software with the server has privacy implications. Although
providing this information is not required, it is encouraged so that providing this information is not required, it is encouraged so that
mail service providers can more effectively inform end-users running mail service providers can more effectively inform end-users running
old clients that they need to upgrade to protect their security, or old clients that they need to upgrade to protect their security, or
know which clients to use in a test deployment prior to upgrading a know which clients to use in a test deployment prior to upgrading a
server to have higher security requirements. server to have higher security requirements.
13. References 15. References
13.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, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 31, line 28 skipping to change at page 31, line 27
<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>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>. <http://www.rfc-editor.org/info/rfc3501>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
DOI 10.17487/RFC3464, January 2003,
<http://www.rfc-editor.org/info/rfc3464>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol
(POP3) Simple Authentication and Security Layer (SASL) (POP3) Simple Authentication and Security Layer (SASL)
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>.
skipping to change at page 32, line 11 skipping to change at page 31, line 48
[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, DOI 10.17487/
RFC5234, January 2008, 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, DOI 10.17487/
RFC5246, August 2008, RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248,
DOI 10.17487/RFC5248, June 2008,
<http://www.rfc-editor.org/info/rfc5248>.
[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
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 32, line 44 skipping to change at page 32, line 28
[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, DOI 10.17487/
RFC6186, March 2011, 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>.
[I-D.ietf-uta-email-tls-certs] [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Melnikov, A., "Updated TLS Server Identity Check Procedure Transport Security (HSTS)", RFC 6797, DOI 10.17487/
for Email Related Protocols", RFC6797, November 2012,
draft-ietf-uta-email-tls-certs-09 (work in progress), <http://www.rfc-editor.org/info/rfc6797>.
December 2015.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<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 2015, <http://www.rfc-editor.org/info/rfc7525>. May 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>.
13.2. Informative References [RFC7817] Melnikov, A., "Updated TLS Server Identity Check Procedure
for Email Related Protocols", RFC 7817, March 2016,
<http://www.rfc-editor.org/info/rfc7817>.
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,
<http://www.rfc-editor.org/info/rfc2979>. <http://www.rfc-editor.org/info/rfc2979>.
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
skipping to change at page 33, line 51 skipping to change at page 33, line 42
[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, DOI 10.17487/
RFC4954, July 2007, 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>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010,
<http://www.rfc-editor.org/info/rfc5802>.
[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
skipping to change at page 34, line 37 skipping to change at page 34, line 21
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 2012, <http://www.rfc-editor.org/info/rfc6698>. August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, DOI 10.17487/
RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>.
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-email-tls-00.txt; subsequent versions merge ideas from draft-moore-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
skipping to change at page 36, line 18 skipping to change at page 35, 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-04:
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
rewrote parts of these two sections to try to make the model
clearer.
o Add text about versioning of security tags to make the model
clearer.
o Add example of security tag upgrade.
o Convert remaining mention of TLS 1.0 to TLS 1.1.
o Change document title from DEEP to MUA STS to align with SMTP
relay STS.
* Slight updates to abstract and introductions.
* Rename security latches/tags to security directives.
* Rename server DEEP status to STS policy.
* Change syntax to use directive-style HSTS syntax.
o Make HSTS reference normative.
o Remove SMTP DSN header as that belongs in SMTP relay STS document.
Changes since draft-ietf-uta-email-deep-03: Changes since draft-ietf-uta-email-deep-03:
o Add more references to ietf-uta-email-tls-certs in implementation o Add more references to ietf-uta-email-tls-certs in implementation
requirements section. requirements section.
o Replace primary reference to RFC 6125 with ietf-uta-email-tls- o Replace primary reference to RFC 6125 with ietf-uta-email-tls-
certs, so move RFC 6125 to informative list for this certs, so move RFC 6125 to informative list for this
specification. specification.
Changes since draft-ietf-uta-email-deep-02: Changes since draft-ietf-uta-email-deep-02:
 End of changes. 160 change blocks. 
473 lines changed or deleted 496 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/