draft-ietf-uta-email-deep-00.txt   draft-ietf-uta-email-deep-01.txt 
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Network Heretics Internet-Draft Network Heretics
Updates: 1939, 3464, 3501, 5068, 6186 C. Newman Updates: 1939, 2595, 3464, 3501, 5068, C. Newman
(if approved) Oracle 6186, 6409 (if approved) Oracle
Intended status: Standards Track February 13, 2015 Intended status: Standards Track July 6, 2015
Expires: August 17, 2015 Expires: January 7, 2016
Deployable Enhanced Email Privacy (DEEP) Deployable Enhanced Email Privacy (DEEP)
draft-ietf-uta-email-deep-00.txt draft-ietf-uta-email-deep-01.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 privacy. This provides mechanisms intended designed to improve email confidentiality between a mail user agent
to increase use of already deployed Transport Layer Security (TLS) (MUA) and a mail submission or mail access server. This provides
technology, provide a model for mail user agent's confidentiality mechanisms intended to increase use of already deployed Transport
assurance, and enable mail service providers to advertise improved Layer Security (TLS) technology, provide a model for mail user
TLS privacy facilities. agent's confidentiality assurance, and enable mail service providers
to advertise improved TLS confidentiality facilities.
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 August 17, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology Used in This Document . . . . . . 4 2. Conventions and Terminology Used in This Document . . . . . . 4
3. Mail Account Confidentiality Assurance Level . . . . . . . . 4 3. Mail Account Confidentiality Assurance Level . . . . . . . . 4
3.1. High Confidentiality Assurance . . . . . . . . . . . . . 5 3.1. High Confidentiality Assurance . . . . . . . . . . . . . 5
3.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 6 3.2. No Confidentiality Assurance . . . . . . . . . . . . . . 6
3.3. No Confidentiality Assurance . . . . . . . . . . . . . . 6 3.3. Other Confidentiality Assurance Levels . . . . . . . . . 6
3.4. Other Confidentiality Assurance Levels . . . . . . . . . 6 4. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . 7
4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP . 8 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP . 8
5. Email Security Upgrading Using Security Latches . . . . . . . 8 5. Email Security Upgrading Using Security Latches . . . . . . . 8
5.1. Email Security Tags . . . . . . . . . . . . . . . . . . . 9 5.1. Email Security Tags . . . . . . . . . . . . . . . . . . . 9
5.2. Initial Set of Email Security Tags . . . . . . . . . . . 10 5.2. Initial Set of Email Security Tags . . . . . . . . . . . 10
5.3. Server DEEP Status . . . . . . . . . . . . . . . . . . . 10 5.3. Server DEEP Status . . . . . . . . . . . . . . . . . . . 10
5.4. Email Security Tag Latch Failures . . . . . . . . . . . . 10 5.4. Email Security Tag Latch Failures . . . . . . . . . . . . 11
6. Recording TLS Cipher Suite in Received Header . . . . . . . . 11 6. Recording TLS Cipher Suite in Received Header . . . . . . . . 11
7. Extensions for DEEP Status and Reporting . . . . . . . . . . 11 7. Extensions for DEEP Status and Reporting . . . . . . . . . . 11
7.1. IMAP DEEP Extension . . . . . . . . . . . . . . . . . . . 12 7.1. IMAP DEEP Extension . . . . . . . . . . . . . . . . . . . 12
7.2. POP DEEP Extension . . . . . . . . . . . . . . . . . . . 14 7.2. POP DEEP Extension . . . . . . . . . . . . . . . . . . . 14
7.3. SMTP DEEP Extension . . . . . . . . . . . . . . . . . . . 15 7.3. SMTP DEEP Extension . . . . . . . . . . . . . . . . . . . 15
7.4. SMTP Error Extension . . . . . . . . . . . . . . . . . . 16 7.4. SMTP Error Extension . . . . . . . . . . . . . . . . . . 16
8. Use of SRV records in Establishing Configuration . . . . . . 16 8. Account Setup Considerations . . . . . . . . . . . . . . . . 16
9. Implementation Requirements . . . . . . . . . . . . . . . . . 17 8.1. Use of SRV records in Establishing Configuration . . . . 16
9.1. All Implementations (Client and Server) . . . . . . . . . 17 8.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 17
9.1.1. Client Certificate Authentication . . . . . . . . . . 18 9. Implementation Requirements . . . . . . . . . . . . . . . . . 18
9.2. Mail Server Implementation Requirements . . . . . . . . . 18 9.1. All Implementations (Client and Server) . . . . . . . . . 18
9.3. Mail User Agent Implementation Requirements . . . . . . . 19 9.1.1. Client Certificate Authentication . . . . . . . . . . 19
9.2. Mail Server Implementation Requirements . . . . . . . . . 19
9.3. Mail User Agent Implementation Requirements . . . . . . . 20
9.4. Non-configurable MUAs and nonstandard access protocols . 20 9.4. Non-configurable MUAs and nonstandard access protocols . 20
9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and
Services . . . . . . . . . . . . . . . . . . . . . . . . 20 Services . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Mail Service Provider Requirements . . . . . . . . . . . . . 20 10. Mail Service Provider Requirements . . . . . . . . . . . . . 21
10.1. Server Requirements . . . . . . . . . . . . . . . . . . 20 10.1. Server Requirements . . . . . . . . . . . . . . . . . . 21
10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 20 10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 21
10.3. TLS Server Certificate Requirements . . . . . . . . . . 21 10.3. TLS Server Certificate Requirements . . . . . . . . . . 22
10.4. Recommended DNS records for mail protocol servers . . . 21 10.4. Recommended DNS records for mail protocol servers . . . 22
10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . 21 10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . 22
10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . 21 10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . 22
10.4.3. TLSA records . . . . . . . . . . . . . . . . . . . . 22 10.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 23
10.4.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 22 10.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . 23
10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . 22 10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . 23
10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 22 10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 23
10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . 22 10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . 23
10.8. Changes to Internet Facing Servers . . . . . . . . . . . 22 10.8. Changes to Internet Facing Servers . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. Security Tag Registry . . . . . . . . . . . . . . . . . 23 11.1. Security Tag Registry . . . . . . . . . . . . . . . . . 24
11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 23 11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 24
11.3. POP3S Port Registration Update . . . . . . . . . . . . . 25 11.3. POP3S Port Registration Update . . . . . . . . . . . . . 26
11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 25 11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 26
11.5. Submissions Port Registration . . . . . . . . . . . . . 26 11.5. Submissions Port Registration . . . . . . . . . . . . . 27
11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 26 11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 27
11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 26 11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 27
11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 27 11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 28
11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . 27 11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . 28
11.10. MAIL Parameters Additional-registered-clauses Sub- 11.10. MAIL Parameters Additional-registered-clauses Sub-
Registry . . . . . . . . . . . . . . . . . . . . . . . . 27 Registry . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 30 13.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Design Considerations . . . . . . . . . . . . . . . 31 Appendix A. Design Considerations . . . . . . . . . . . . . . . 32
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 32 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 33
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 33 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 34
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 35 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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] and/ Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] and/
or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually
has Transport Layer Security (TLS) [RFC5246] support but often does has Transport Layer Security (TLS) [RFC5246] support but often does
not use it in a way that maximizes end-user confidentiality. This not use it in a way that maximizes end-user confidentiality. This
specification proposes changes to email software and deployments specification proposes changes to email software and deployments
intended to increase the use of TLS and record when that use occurs. intended to increase the use of TLS and record when that use occurs.
skipping to change at page 3, line 50 skipping to change at page 4, line 6
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/privacy feature use and in this specification) to upgrade security feature use and record/
record/indicate that usage appropriately. indicate that usage appropriately.
Improved use of TLS with SMTP for message relaying is described in a This does not address use of TLS with SMTP for message relay (where
separate document [I-D.ietf-dane-smtp-with-dane]. Message Submission [RFC6409] does not apply). Improved use of TLS
with SMTP for message relay requires a different approach. Future
work may address that topic and one approach is described in
[I-D.ietf-dane-smtp-with-dane].
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.
This draft is subject to change. Implementation of this proposal is This draft is subject to change. Implementation of this proposal is
not recommended at this time. Please discuss this proposal on the not recommended at this time. Please discuss this proposal on the
ietf-uta mailing list. ietf-uta mailing list.
2. Conventions and Terminology Used in This Document 2. Conventions and Terminology Used in This Document
skipping to change at page 5, line 37 skipping to change at page 5, line 44
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.melnikov-email-tls-certs] and PKIX o MUAs MUST implement [I-D.ietf-uta-email-tls-certs] 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 privacy The end user is part of the system that protects the user's
and security. As a result, it's critical not to present the end user confidentiality and security. As a result, it's critical not to
with a simple action that reduces their privacy in response to present the end user with a simple action that reduces their
certificate validation failure. An MUA which offers a user actions confidentiality in response to certificate validation failure. An
such as "connect anyway", "trust certificate for future connections" MUA which offers a user actions such as "connect anyway", "trust
or "lower confidentiality assurance for this account" in response to certificate for future connections" or "lower confidentiality
certificate validation failure is not providing a high assurance for this account" in response to certificate validation
confidentiality assurance as defined in this section and thus does failure is not providing a high confidentiality assurance as defined
not comply with this document. Examples of acceptable actions to in this section and thus does not comply with this document.
offer would be "work offline", "try again later", and "open service Examples of acceptable actions to offer would be "work offline", "try
provider status web page". again later", and "open service provider status web page".
3.2. Certificate Pinning
MUAs MAY implement certificate pinning as part of account setup, but
MUST NOT offer this as an option in response to a failed certificate
validation for an existing account. Certificate pinning occurs when
the user agent saves a server certificate with the account settings
and trusts that certificate for subsequent connections to that
server. An MUA that allows certificate pinning MUST NOT allow a
certificate pinned for one account to validate connections for other
accounts.
A pinned certificate is subject to a man-in-the-middle attack at
account setup time, and lacks a mechanism to revoke or securely
refresh the certificate. Therefore use of a pinned certificate does
not provide a high confidentiality assurance and an MUA MUST NOT
indicate a high level for an account or connection using a pinned
certificate.
3.3. 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.0 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.4. 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 privacy. 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
may be confused by too many confidentiality assurance levels. may be confused by too many confidentiality assurance levels.
4. Implicit TLS 4. Implicit TLS
Previous standards for use of email protocols with TLS used the Previous standards for use of email protocols with TLS used the
STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With
STARTTLS, the client establishes a clear text application session and STARTTLS, the client establishes a clear text application session and
skipping to change at page 7, line 25 skipping to change at page 7, line 14
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.melnikov-email-tls-certs]. Once the TLS session is established, [I-D.ietf-uta-email-tls-certs]. Once the TLS session is established,
POP3 [RFC1939] protocol messages are exchanged as TLS application POP3 [RFC1939] protocol messages are exchanged as TLS application
data for the remainder of the TCP connection. After the server sends data for the remainder of the TCP connection. After the server sends
a +OK greeting, the server and client MUST enter AUTHORIZATION state, a +OK greeting, the server and client MUST enter AUTHORIZATION state,
even if client credentials were supplied during the TLS handshake. even if client credentials were supplied during the TLS handshake.
See Section 9.1.1 for additional information on client certificate See Section 9.1.1 for additional information on client certificate
authentication. See Section 11.3 for port registration information. authentication. See Section 11.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.melnikov-email-tls-certs]. Once the TLS session is in [I-D.ietf-uta-email-tls-certs]. Once the TLS session is
established, IMAP [RFC3501] protocol messages are exchanged as TLS established, IMAP [RFC3501] protocol messages are exchanged as TLS
application data for the remainder of the TCP connection. If client application data for the remainder of the TCP connection. If client
credentials were provided during the TLS handshake that the server credentials were provided during the TLS handshake that the server
finds acceptable, the server MAY issue a PREAUTH greeting in which finds acceptable, the server MAY issue a PREAUTH greeting in which
case both the server and client enter AUTHENTICATED state. If the case both the server and client enter AUTHENTICATED state. If the
server issues an OK greeting then both server and client enter NOT server issues an OK greeting then both server and client enter NOT
AUTHENTICATED state. AUTHENTICATED state.
See Section 9.1.1 for additional information on client certificate See Section 9.1.1 for additional information on client certificate
authentication. See Section 11.4 for port registration information. authentication. See Section 11.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.melnikov-email-tls-certs]. Once a TLS session is established, [I-D.ietf-uta-email-tls-certs]. Once a TLS session is established,
message submission protocol data [RFC6409] is exchanged as TLS message submission protocol data [RFC6409] is exchanged as TLS
application data for the remainder of the TCP connection. (Note: the application data for the remainder of the TCP connection. (Note: the
"submissions" service name is defined in section 10.3 of this "submissions" service name is defined in section 10.3 of this
document, and follows the usual convention that the name of a service document, and follows the usual convention that the name of a service
layered on top of Implicit TLS consists of the name of the service as layered on top of Implicit TLS consists of the name of the service as
used without TLS, with an "s" appended.) used without TLS, with an "s" appended.)
The STARTTLS mechanism on port 587 is relatively widely deployed due
to the situation with port 465 (discussed in Section 11.5). This
differs from IMAP and POP services where implicit TLS is more widely
deployed on servers than STARTTLS. It is desirable to migrate MUA
software to implicit TLS over time for consistency as well as the
reasons discussed elsewhere in this document. However, to maximize
use of encryption for submission it is desirable to support both
mechanisms for Message Submission over TLS for a transition period of
several years. As a result, clients and servers SHOULD implement
both STARTTLS on port 587 and implicit TLS on port 465 for this
transition period. Note that there is no significant difference
between the security properties of STARTTLS on port 587 and implicit
TLS on port 465 if the implementations are correct and both client
and server are configured to require successful negotiation of TLS
prior to message submission (as required in Section 9.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 9.1.1 for additional information on client certificate
authentication. See Section 11.5 for port registration information. authentication. See Section 11.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 Latches
Once an improved email security or privacy mechanism is deployed and Once an improved email security mechanism is deployed and ready for
ready for general use, it is desirable to continue using it for all general use, it is desirable to continue using it for all future
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
skipping to change at page 9, line 15 skipping to change at page 9, line 22
all downgrade attacks. However, this sort of security policy upgrade all 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 latches", which
is designed to permit an MUA to recognize when a service provider has is designed to permit an MUA to recognize when a service provider has
committed to provide certain server security features, and that it's committed to provide certain server security features, and that it's
safe for the client to change its configuration for that account to safe for the client to change its configuration for that account to
require that such features be present in future sessions with that require that such features be present in future sessions with that
server. When an MUA implements both confidentiality assurance levels server. When an MUA implements both confidentiality assurance levels
and security latches, then both the end-user and the service provider and security latches, then both the end-user and the service provider
independently have the ability to improve the end-user's privacy. independently have the ability to improve the end-user's
confidentiality.
Note that security latches are a mechanism similar to HTTP Strict Note that security latches are a mechanism similar to HTTP Strict
Transport Security (HSTS) [RFC6797] but are extensible. Transport Security (HSTS) [RFC6797] but are extensible.
5.1. Email Security Tags 5.1. Email Security Tags
Each security latch is given a name known as an email security tag. Each security latch is given a name known as an email security tag.
An email security tag is a short alphanumeric token that represents a 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 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 session. When a server advertises a security tag it is making a
skipping to change at page 11, line 20 skipping to change at page 11, line 26
6. Recording TLS Cipher Suite in Received Header 6. 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_DHE_RSA_WITH_AES_128_CBC_SHA) included cipher suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
in the TLS cipher suite registry. In the event the implementation included in the TLS cipher suite registry. In the event the
does not know the name of the cipher suite (a situation that should implementation does not know the name of the cipher suite (a
be remedied promptly), a four-digit hexadecimal cipher suite situation that should be remedied promptly), a four-digit hexadecimal
identifier MAY be used. The ABNF for the field follows: cipher suite identifier MAY be used. The ABNF for the field follows:
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
skipping to change at page 13, line 11 skipping to change at page 13, line 11
and determine the server DEEP status. Clients MAY use the ID command and determine the server DEEP status. Clients MAY use the ID command
to report other latch or security tag information. IMAP servers MUST to report other latch or security tag information. IMAP servers MUST
implement the ID command at least to report DEEP status to clients. implement the ID command at least to report DEEP status 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 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" "latch"
"tls10 tls-cert" "security-tags" "tls12") "tls10 tls-cert" "security-tags" "tls12")
S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" S: * ID ("name" "Demo Server" "version" "1.7" "deep-status"
"<https://www.example.com/privacy-support.html>") "<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.0 or later and verified the server's certificate as required by
IMAP. The client supports TLS 1.2. However, even if the client IMAP. The client supports TLS 1.2. However, even if the client
successfully negotiated TLS 1.2, it will not latch that security tag successfully negotiated TLS 1.2, it will not latch that security tag
automatically because the server did not advertise that tag. If the automatically because the server did not advertise that tag. If the
client successfully validated the server certificate, it will latch client successfully validated the server certificate, it will latch
the provided URL. 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" "latch-failure"
"tls-cert") "tls-cert")
S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" S: * ID ("name" "Demo Server" "version" "1.7" "deep-status"
"tls10 <https://www.example.com/privacy-support.html>") "tls10 <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 latch-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 deep-
status in this exchange is ignored due to the latch failure. status 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" "latch"
"tls10 tls-cert" "security-tags" "tls12" "tls10 tls-cert" "security-tags" "tls12"
"tls" "TLS_RSA_WITH_AES_128_CBC_SHA") "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" "deep-status"
"tls10 tls-cert <https://www.example.com/support.html>") "tls10 tls-cert <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
skipping to change at page 14, line 39 skipping to change at page 14, line 39
<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 tls10 tls12 <https://www.example.com/privacy-support.html> S: DEEP tls10 tls12 <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 latch any or all of the DEEP status. If the client
connects to this same server later and has a security failure, the connects to this same server later and has a security failure, the
client can direct the user's browser to the previously-latched URI client can direct the user's browser to the previously-latched URI
where the service provider may provide advice to the end user. where the service provider may provide advice to the end user.
skipping to change at page 16, line 13 skipping to change at page 16, line 13
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 tls10 tls-cert <https://www.example.com/status.html> S: 250-DEEP g tls-cert <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=tls10,tls-cert C: CLIENT name=demo_submit version=1.5 latch=tls10,tls-cert
security-tags=tls12 security-tags=tls12
S: 250 OK S: 250 OK
Example 5 Example 5
7.4. SMTP Error Extension 7.4. SMTP Error Extension
skipping to change at page 16, line 40 skipping to change at page 16, line 40
that includes a space-delimited list including one or more security that includes a space-delimited list including one or more security
latch that failed. The ABNF for this new field follows: latch that failed. The ABNF for this new field follows:
CFWS = <defined in RFC 5322> CFWS = <defined in RFC 5322>
FWS = <defined in RFC 5322> FWS = <defined in RFC 5322>
smtp-security-latch = "SMTP-Security-Latch:" CFWS smtp-security-latch = "SMTP-Security-Latch:" CFWS
security-tag *(FWS security-tag) security-tag *(FWS security-tag)
8. Use of SRV records in Establishing Configuration 8. Account Setup Considerations
8.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 17, line 36 skipping to change at page 17, line 37
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
During account setup, the MUA will identify servers that provide
account services such as mail access and mail submission (the
previous section describes one way to do this). The certificates for
these servers are verified using the rules described in
[I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. In the event the
certificate does not validate due to an expired certificate, lack of
appropriate chain of trust or lack of identifier match, the MUA MAY
create a persistent binding between that certificate and the saved
host name for the server. This is called certificate pinning.
Certificate pinning is only appropriate during account setup and MUST
NOT be offered in response to a failed certificate validation for an
existing account. An MUA that allows certificate pinning MUST NOT
allow a certificate pinned for one account to validate connections
for other accounts.
A pinned certificate is subject to a man-in-the-middle attack at
account setup time, and lacks a mechanism to revoke or securely
refresh the certificate. Therefore use of a pinned certificate does
not provide a high confidentiality assurance and an MUA MUST NOT
indicate a high level for an account or connection using a pinned
certificate. Additional advice on certificate pinning is present in
[RFC6125].
9. Implementation Requirements 9. 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) 9.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] including support using the TLS 1.2 protocol or later [RFC5246].
for the mandatory-to-implement TLS 1.2 cipher suite
TLS_RSA_WITH_AES_128_CBC_SHA.
o IMAP implementations MUST support the IMAP4rev1 mandatory-to- o All implementations MUST implement the recommended cipher suites
implement cipher suite TLS_RSA_WITH_RC4_128_MD5 for any described in [RFC7525] or a future BCP or standards track revision
connections made or received via IMAP although this MAY be of that document.
disabled by default.
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
second paragraph of section 11.1 and replace it with the text from
the first three bullet items in this list.
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
the first three bullet items in this list.
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
require implementation of the TLS server identity check as
described in [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280].
9.1.1. Client Certificate Authentication 9.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
skipping to change at page 20, line 23 skipping to change at page 21, line 11
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 9.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 to the real MTA. Deploying AVAS services in perform a scan and proxy or forward to another MTA. Deploying AVAS
this way can cause many problems [RFC2979] including direct services in this way can cause many problems [RFC2979] including
interference with DEEP and confidentiality or security reduction. An direct interference with DEEP and confidentiality or security
AVAS product or service is considered DEEP compliant if all IMAP, POP reduction. An AVAS product or service is considered DEEP compliant
and SMTP-related software it includes is DEEP compliant and it if all IMAP, POP and SMTP-related software it includes is DEEP
advertises and supports all security latches that the actual MTA compliant and it advertises and supports all security latches that
advertises. the actual servers advertise.
Note that end-to-end email encryption prevents AVAS software and
services from using email content as part of a spam or virus
assessment. Furthermore, while DEEP high confidentiality assurance
can prevent a man-in-the-middle from introducing spam or virus
content between the MUA and Submission server, it does not prevent
other forms of client or account compromise so use of AVAS services
for submitted email remains necessary.
10. Mail Service Provider Requirements 10. 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 10.1. Server Requirements
Mail Service Providers MUST use server implementations that conform Mail Service Providers MUST use server implementations that conform
skipping to change at page 22, line 5 skipping to change at page 23, line 5
for this document. for this document.
10.4.2. SRV records 10.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. TLSA records 10.4.3. DNSSEC
All DNS records advertised by an MSP as a means of aiding clients in
communicating with the MSP's servers, SHOULD be signed using DNSSEC.
10.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.4.4. DNSSEC
All DNS records advertised by an MSP as a means of aiding clients in
communicating with the MSP's servers, SHOULD be signed using DNSSEC.
10.5. MSP Server Monitoring 10.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
skipping to change at page 23, line 31 skipping to change at page 24, line 31
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 tag name follows the ABNF, and
that the description field is clear, unambiguous, does not overlap that the description field is clear, unambiguous, does not overlap
existing deployed technology, does not create security or privacy existing deployed technology, does not create security problems and
problems and appropriately considers interoperability issues. Email appropriately considers interoperability issues. Email security tags
security tags intended for LIMITED USE have a lower review bar intended for LIMITED USE have a lower review bar (interoperability
(interoperability and overlap issues are less of a concern). The and overlap issues are less of a concern). The reviewer may approve
reviewer may approve a registration, reject for a stated reason or a registration, reject for a stated reason or recommend the proposal
recommend the proposal have standards track review due to importance have standards track review due to importance or difficult
or difficult subtleties. 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 11.2. Initial Set of Security Tags
skipping to change at page 28, line 17 skipping to change at page 29, line 17
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 6
Reference: This document. Reference: This document.
12. Security Considerations 12. 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 privacy and to mitigate threats this is targeted to improve mail confidentiality and to mitigate
external to the email system such as network-level snooping or threats external to the email system such as network-level snooping
interception; this is not intended to mitigate active attackers who or interception; this is not intended to mitigate active attackers
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 13. References
skipping to change at page 30, line 11 skipping to change at page 31, line 11
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[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, March 2011. Submission/Access Services", RFC 6186, March 2011.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, November 2011. STD 72, RFC 6409, November 2011.
[I-D.melnikov-email-tls-certs] [I-D.ietf-uta-email-tls-certs]
Melnikov, A., "Updated TLS Server Identity Check Procedure Melnikov, A., "Updated TLS Server Identity Check Procedure
for Email Related Protocols", draft-melnikov-email-tls- for Email Related Protocols", draft-ietf-uta-email-tls-
certs-01 (work in progress), October 2013. certs-03 (work in progress), June 2015.
[I-D.ietf-dane-smtp-with-dane] [I-D.ietf-dane-smtp-with-dane]
Dukhovni, V. and W. Hardaker, "SMTP security via Dukhovni, V. and W. Hardaker, "SMTP security via
opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-02 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-02
(work in progress), October 2013. (work in progress), October 2013.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
13.2. Informative References 13.2. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
2595, June 1999. 2595, June 1999.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet [RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000. Firewalls", RFC 2979, October 2000.
skipping to change at page 32, line 43 skipping to change at page 34, line 5
will just create interoperability problems. Registering a port will just create interoperability problems. Registering a port
that's only used if advertised by an SRV record (RFC 6186) would that's only used if advertised by an SRV record (RFC 6186) would
not create interoperability problems but would require all client not create interoperability problems but would require all client
and server deployments and software to change significantly which and server deployments and software to change significantly which
is contrary to the goal of promoting more TLS use. Encouraging is contrary to the goal of promoting more TLS use. Encouraging
use of STARTTLS on port 587 would not create interoperability use of STARTTLS on port 587 would not create interoperability
problems, but is unlikely to have impact on current undocumented problems, but is unlikely to have impact on current undocumented
use of port 465 and makes the guidance in this document less use of port 465 and makes the guidance in this document less
consistent. consistent.
o This document should reference draft-ietf-uta-tls-bcp and possibly
other guidance documents. Suggested text on where/how to
reference this and possibly other TLS guidance (e.g., must
staple). would be welcome.
o One author believes that the security latch model is complementary o One author believes that the security latch model is complementary
with draft-ietf-dane-smtp-with-dane-02 but hasn't thought about with draft-ietf-dane-smtp-with-dane-02 but hasn't thought about
the issues in depth. We welcome feedback on this point. the issues in depth. We welcome feedback on this point.
o The two authors of this document and the author of draft-melnikov- o The two authors of this document and the author of draft-melnikov-
email-tls-certs are willing to merge these two documents. email-tls-certs are willing to merge these two documents.
However, it is undesirable to delay publication of either document However, it is undesirable to delay publication of either document
so this will be done only if the latter document is not yet so this will be done only if the latter document is not yet
through IESG processing when this document is ready for the IESG. through IESG processing when this document is ready for the IESG.
o It might make sense to split this in two or more documents if it's o It might make sense to split this in two or more documents if it's
getting too long to evaluate in one IETF last call. In getting too long to evaluate in one IETF last call. In
particular, it might make sense to put implementation requirements particular, it might make sense to put implementation requirements
and service provider requirements in separate documents. The and service provider requirements in separate documents. The
authors prefer to edit one document for now and defer discussion authors prefer to edit one document for now and defer discussion
of splitting the document until all technical issues are resolved. of splitting the document until all technical issues are resolved.
o The use of SRV records [RFC6186] for account setup or refresh is o The use of SRV records [RFC6186] for account setup or refresh is
presently not secure from DNS active attacks unless DNSSEC is presently not secure from DNS active attacks unless DNSSEC is
used. As this document is now focusing on MUA security/privacy, used. If someone wishes to provide suggested text describing how
discussing how to do SRV record account setup or account refresh to use DANE in this process, the WG can consider adding that text
securely, probably using DANE, would be in scope for this to this document. Absent suggested text, the editor intends to
document. It has been suggested that we add this. leave this issue alone.
o This document does not cover use of TLS with SMTP relay.
Appendix C. Change Log Appendix C. Change Log
Changes since draft-ietf-uta-email-deep-00:
o Update and clarify abstract
o use term confidentiality instead of privacy in most cases.
o update open issues to request input for missing text.
o move certificate pinning sub-section to account setup section and
attempt to define it more precisely.
o Add note about end-to-end encryption in AVAS section.
o swap order of DNSSEC and TLSA sub-sections.
o change meaning of 'tls10' and 'tls12' latches to require
certificate validation.
o Replace cipher suite advice with reference to RFC 7525. Change
examples to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as cipher
suite.
o Add text to update IMAP, POP3 and Message Submission standards
with newer TLS advice.
o Add clearer text in introduction that this does not cover SMTP
relay.
o Update references to uta-tls-certs.
o Add paragraph to Implicit TLS for SMTP Submission section
recommending that STARTTLS also be implemented.
Changes since draft-newman-email-deep-02: Changes since draft-newman-email-deep-02:
o Changed "privacy assurance" to "confidentiality assurance" o Changed "privacy assurance" to "confidentiality assurance"
o Changed "low privacy assurance" to "no confidentiality assurance" o Changed "low privacy assurance" to "no confidentiality assurance"
o Attempt to improve definition of confidentiality assurance level. o Attempt to improve definition of confidentiality assurance level.
o Add SHOULD indicate when MUA is showing list of mail accounts. o Add SHOULD indicate when MUA is showing list of mail accounts.
skipping to change at page 35, line 7 skipping to change at page 36, line 45
o Add DNS SRV section from draft-moore-email-tls-00. o Add DNS SRV section from draft-moore-email-tls-00.
o Write most of the missing IANA considerations section. o Write most of the missing IANA considerations section.
o Rewrite most of implementation requirements section based more on o Rewrite most of implementation requirements section based more on
draft-moore-email-tls-00. Remove new cipher requirements for now draft-moore-email-tls-00. Remove new cipher requirements for now
because those may be dealt with elsewhere. because those may be dealt with elsewhere.
Appendix D. Acknowledgements Appendix D. Acknowledgements
Many thanks to Ned Freed for discussion of the initial latch concepts Thanks to Ned Freed for discussion of the initial latch concepts in
in this document. Thanks to Alexey Melnikov for draft-melnikov-pop3- this document. Thanks to Alexey Melnikov for draft-melnikov-pop3-
over-tls-02, which was the basis of the POP3 implicit TLS text. over-tls-02, which was the basis of the POP3 implicit TLS text.
Thanks to Dan Newman and Alexey Melnikov for review feedback. Thanks Thanks to Russ Housley, Alexey Melnikov and Dan Newman for review
to Paul Hoffman for interesting feedback in initial conversations feedback. Thanks to Paul Hoffman for interesting feedback in initial
about this idea. conversations about this idea.
Authors' Addresses Authors' Addresses
Keith Moore Keith Moore
Network Heretics Network Heretics
PO Box 1934 PO Box 1934
Knoxville, TN 37901 Knoxville, TN 37901
US US
Email: moore@network-heretics.com Email: moore@network-heretics.com
 End of changes. 47 change blocks. 
162 lines changed or deleted 242 lines changed or added

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