draft-ietf-uta-email-deep-01.txt   draft-ietf-uta-email-deep-02.txt 
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Network Heretics Internet-Draft Network Heretics
Updates: 1939, 2595, 3464, 3501, 5068, C. Newman Updates: 1939, 2595, 3464, 3501, 5068, C. Newman
6186, 6409 (if approved) Oracle 6186, 6409 (if approved) Oracle
Intended status: Standards Track July 6, 2015 Intended status: Standards Track March 10, 2016
Expires: January 7, 2016 Expires: September 11, 2016
Deployable Enhanced Email Privacy (DEEP) Deployable Enhanced Email Privacy (DEEP)
draft-ietf-uta-email-deep-01.txt draft-ietf-uta-email-deep-02.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, provide a model for mail user
agent's confidentiality assurance, and enable mail service providers agent's confidentiality assurance, and enable mail service providers
to advertise improved TLS confidentiality facilities. 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 January 7, 2016. This Internet-Draft will expire on September 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . 4 3. Mail Account Confidentiality Assurance Level . . . . . . . . . 5
3.1. High Confidentiality Assurance . . . . . . . . . . . . . 5 3.1. High Confidentiality Assurance . . . . . . . . . . . . . 6
3.2. No Confidentiality Assurance . . . . . . . . . . . . . . 6 3.2. No Confidentiality Assurance . . . . . . . . . . . . . . 6
3.3. Other Confidentiality Assurance Levels . . . . . . . . . 6 3.3. Other Confidentiality Assurance Levels . . . . . . . . . 7
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 . . . . . . . . . . . . 7 4.3. Implicit TLS for SMTP Submission . . . . . . . . . . . . 8
4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP . 8 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP . 9
5. Email Security Upgrading Using Security Latches . . . . . . . 8 5. Email Security Upgrading Using Security Latches . . . . . . . 9
5.1. Email Security Tags . . . . . . . . . . . . . . . . . . . 9 5.1. Email Security Tags . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . 11 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 . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . 17
8. Account Setup Considerations . . . . . . . . . . . . . . . . 16 8. Account Setup Considerations . . . . . . . . . . . . . . . . . 17
8.1. Use of SRV records in Establishing Configuration . . . . 16 8.1. Use of SRV records in Establishing Configuration . . . . 17
8.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 17 8.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 18
9. Implementation Requirements . . . . . . . . . . . . . . . . . 18 9. Implementation Requirements . . . . . . . . . . . . . . . . . 18
9.1. All Implementations (Client and Server) . . . . . . . . . 18 9.1. All Implementations (Client and Server) . . . . . . . . . 19
9.1.1. Client Certificate Authentication . . . . . . . . . . 19 9.1.1. Client Certificate Authentication . . . . . . . . . . 19
9.2. Mail Server Implementation Requirements . . . . . . . . . 19 9.2. Mail Server Implementation Requirements . . . . . . . . . 20
9.3. Mail User Agent Implementation Requirements . . . . . . . 20 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 . 21
9.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
10. Mail Service Provider Requirements . . . . . . . . . . . . . 21 10. Mail Service Provider Requirements . . . . . . . . . . . . . . 22
10.1. Server Requirements . . . . . . . . . . . . . . . . . . 21 10.1. Server Requirements . . . . . . . . . . . . . . . . . . . 22
10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 21 10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 22
10.3. TLS Server Certificate Requirements . . . . . . . . . . 22 10.3. TLS Server Certificate Requirements . . . . . . . . . . . 22
10.4. Recommended DNS records for mail protocol servers . . . 22 10.4. Recommended DNS records for mail protocol servers . . . . 23
10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . 22 10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . . 23
10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . 22 10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . . 23
10.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 23 10.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 23
10.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . 23 10.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . . 23
10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . 23 10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . . 23
10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 23 10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 24
10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . 23 10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . . 24
10.8. Changes to Internet Facing Servers . . . . . . . . . . . 23 10.8. Changes to Internet Facing Servers . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. Security Tag Registry . . . . . . . . . . . . . . . . . 24 11.1. Security Tag Registry . . . . . . . . . . . . . . . . . . 24
11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 24 11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 25
11.3. POP3S Port Registration Update . . . . . . . . . . . . . 26 11.3. POP3S Port Registration Update . . . . . . . . . . . . . 27
11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 26 11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 27
11.5. Submissions Port Registration . . . . . . . . . . . . . 27 11.5. Submissions Port Registration . . . . . . . . . . . . . . 28
11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 27 11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 28
11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 27 11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 29
11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 28 11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 29
11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . 28 11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . . 29
11.10. MAIL Parameters Additional-registered-clauses Sub- 11.10. MAIL Parameters Additional-registered-clauses
Registry . . . . . . . . . . . . . . . . . . . . . . . . 28 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 29 13.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Design Considerations . . . . . . . . . . . . . . . 32 Appendix A. Design Considerations . . . . . . . . . . . . . . . . 33
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 33 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 34 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 37
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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]
or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409]
has Transport Layer Security (TLS) [RFC5246] support but often does usually has Transport Layer Security (TLS) [RFC5246] support but
not use it in a way that maximizes end-user confidentiality. This often does not use it in a way that maximizes end-user
specification proposes changes to email software and deployments confidentiality. This specification proposes changes to email
intended to increase the use of TLS and record when that use occurs. software and deployments intended to increase the use of TLS and
record when that use occurs.
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;
skipping to change at page 9, line 38 skipping to change at page 10, line 15
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
commitment to support that security facility indefinitely and commitment to support that security facility indefinitely and
recommending that the client save that security tag with the account recommending that the client save that security tag with the account
configuration and require that security feature for future configuration and require that security feature for future
connections to that server. When a security tag is saved by the connections to that server. When a security tag is saved by the
client in this way, it is then considered latched. For the "tls10" client in this way, it is then considered latched. For the "tls11"
and/or "tls12" tags, the client SHOULD refuse to connect to the and/or "tls12" tags, the client SHOULD refuse to connect to the
server unless the appropriate level of TLS is successfully server unless the appropriate level of TLS is successfully
negotiated. The client SHOULD NOT latch these two tags until TLS has negotiated. The client SHOULD NOT latch tags unless they are
been successfully negotiated as described in the tag definition. If advertised by the server, TLS is active and the client successfully
the tags are advertised within an appropriate TLS-protected authenticates the server with the TLS session. Once a security tag
connection, the client SHOULD latch these tags. Other security tags is latched, all subsequent connections to that host require that
are latched if they are advertised by the server, TLS is active and security feature. For this confidentiality protection to work as
the client successfully authenticates the server with the TLS desired clients MUST NOT offer a click-through-to-connect action when
session. Once a security tag is latched, all subsequent connections unable to achieve connection security matching the latched security
to that host require that security feature. For this confidentiality tags.
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: An identifier for a security tag has the following formal syntax:
security-tag = ALPHA *63(ALPHA / DIGIT / "-" / "_") security-tag = ALPHA *63(ALPHA / DIGIT / "-" / "_")
5.2. Initial Set of Email Security Tags 5.2. Initial Set of Email Security Tags
This section describes an initial set of email security tags. The This section describes an initial set of email security tags. The
IANA Considerations Section 11 defines a registry so that more tags 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 can be defined in the future. The initial set of tags are defined in
Section 11.2 and include tls10, tls12, tls-cert and tls-dane-tlsa. Section 11.2 and include tls11, tls12, tls-cert and tls-dane-tlsa.
5.3. Server DEEP Status 5.3. Server DEEP Status
Servers supporting this extension MUST advertise a DEEP status. This Servers supporting this extension MUST advertise a DEEP status. This
status includes a list of security-tags the server administrator has status includes a list of security-tags the server administrator has
explicitly configured as recommended for use by end-users (the list explicitly configured as recommended for use by end-users (the list
MAY be empty), an optional https Uniform Resource Locator (URL) MAY be empty), an optional https Uniform Resource Locator (URL)
[RFC2818] that the client can save and subsequently resolve for the [RFC2818] that the client can save and subsequently resolve for the
user in the event of a security connection problem, and the DEEP user in the event of a security connection problem, and the DEEP
status can be extended by future updates to this specification. DEEP status can be extended by future updates to this specification. DEEP
skipping to change at page 10, line 49 skipping to change at page 11, line 27
The syntax for a Uniform Resource Identifier (URI) is defined in The syntax for a Uniform Resource Identifier (URI) is defined in
[RFC3986]. Protocol extensions to advertise DEEP status are defined [RFC3986]. Protocol extensions to advertise DEEP status are defined
in Section 7. in Section 7.
If the client successfully negotiates TLS and authenticates the If the client successfully negotiates TLS and authenticates the
server (e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with server (e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with
channel bindings [RFC5802]), then the client SHOULD record the channel bindings [RFC5802]), then the client SHOULD record the
server's DEEP status information in the account configuration with server's DEEP status information in the account configuration with
the server's hostname. Otherwise, the client SHOULD ignore the the server's hostname. Otherwise, the client SHOULD ignore the
server-provided DEEP status except for the "tls10" and "tls12" server-provided DEEP status.
security tags.
5.4. Email Security Tag Latch Failures 5.4. Email Security Tag Latch Failures
When a security tag latch has been set for connections from a client When a security tag latch has been set for connections from a client
to a server and the property identified by that tag is no longer to a server and the property identified by that tag is no longer
available, this results in a connection failure. An MUA SHOULD available, this results in a connection failure. An MUA SHOULD
inform the user of a potential threat to their confidentiality and inform the user of a potential threat to their confidentiality and
offer to resolve a previously-recorded DEEP status https URL if one offer to resolve a previously-recorded DEEP status 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 latches as this defeats the benefit they
skipping to change at page 13, line 9 skipping to change at page 13, line 30
IMAP clients SHOULD use the IMAP ID command to report latch failures IMAP clients SHOULD use the IMAP ID command to report latch failures
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") "tls11 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/security-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/security-support.html>") "tls11 <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" "tls11 tls-cert" "security-tags" "tls12"
"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" "deep-status"
"tls10 tls-cert <https://www.example.com/support.html>") "tls11 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
on the connection from the client. on the connection from the client.
skipping to change at page 14, line 39 skipping to change at page 15, line 14
<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/security-support.html> S: DEEP tls11 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 43
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 g tls-cert <https://www.example.com/status.html> S: 250-DEEP tls12 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=tls11,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
Although this document focuses on SMTP Submission, it is possible to Although this document focuses on SMTP Submission, it is possible to
use security latches for SMTP transport as well. When MTA transport use security latches for SMTP transport as well. When MTA transport
fails due to a security latch, the MTA MUST use the SMTP enhanced fails due to a security latch, the MTA MUST use the SMTP enhanced
skipping to change at page 20, line 21 skipping to change at page 21, line 6
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 latches are pre-set, the number of
trust anchors, certificate validity, use of an extended validation trust anchors, certificate validity, use of an extended validation
certificate, TLS version supported, and TLS cipher suites certificate, TLS version supported, and TLS cipher suites
supported by both server and client. This indication SHOULD also supported by both server and client. This indication SHOULD also
be present when editing or viewing account configuration. 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 tls10 latch if the server available for a protocol and set the tls11 latch if the server
advertises the tls10 security tag after a successful TLS advertises the tls11 security tag after a successful TLS
negotiation. 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 "tls12" security latch (the TLS library
skipping to change at page 23, line 31 skipping to change at page 24, line 11
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 10.6. Advertisement of DEEP status
MSPs SHOULD advertise a DEEP status that includes tls10, 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 10.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.
skipping to change at page 24, line 51 skipping to change at page 25, line 33
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
This document defines four initial security tags for the security tag This document defines four initial security tags for the security tag
registry as follows: registry as follows:
Name: tls10 Name: tls11
Description: This indicates TLS version 1.0 [RFC2246] or later was
Description: This indicates TLS version 1.1 [RFC4346] or later was
negotiated successfully including negotiation of a strong negotiated successfully including negotiation of a strong
encryption layer with a symmetric key of at least 128 bits. This encryption layer with a symmetric key of at least 128 bits. This
tag does not indicate the server certificate was valid. This tag tag indicates the server certificate was valid but does not
is latched if the client sees this tag in the advertised server indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE
DEEP status provided after successfully negotiating TLS version [RFC6698]). This tag is latched if the client sees this tag in
1.0 or later. the advertised server DEEP status provided after successfully
negotiating TLS version 1.0 or later.
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: tls12 Name: tls12
Description: This indicates TLS version 1.2 [RFC5246] or later was Description: This indicates TLS version 1.2 [RFC5246] or later was
negotiated successfully including negotiation of a strong negotiated successfully including negotiation of a strong
encryption layer with a symmetric key of at least 128 bits. This encryption layer with a symmetric key of at least 128 bits. This
tag does not indicate the server certificate was valid. This tag tag indicates the server certificate was valid but does not
is latched if the client sees this tag in the advertised server indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE
DEEP status provided after successfully negotiating TLS version [RFC6698]). This tag is latched if the client sees this tag in
1.2 or later. the advertised server DEEP status provided after successfully
negotiating TLS version 1.2 or later.
Intended Usage: COMMON Intended Usage: COMMON
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Submitter: Authors of this document Submitter: Authors of this document
Change Controller: IESG Change Controller: IESG
Name: tls-cert Name: tls-cert
skipping to change at page 26, line 38 skipping to change at page 27, line 25
IANA is asked to update the registration of the TCP well-known port IANA is asked to update the registration of the TCP well-known port
995 using the following template ([RFC6335]): 995 using the following template ([RFC6335]):
Service Name: pop3s Service Name: pop3s
Transport Protocol: TCP Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org> Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: POP3 over TLS protocol Description: POP3 over TLS protocol
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Port Number: 995
Service Name: pop3s
Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: POP3 over TLS protocol
Reference: RFC XXXX (this document once published)
11.4. IMAPS Port Registration Update 11.4. IMAPS Port Registration Update
IANA is asked to update the registration of the TCP well-known port IANA is asked to update the registration of the TCP well-known port
993 using the following template ([RFC6335]): 993 using the following template ([RFC6335]):
Service Name: imaps Service Name: imaps
Transport Protocol: TCP Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org> Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: IMAP over TLS protocol Description: IMAP over TLS protocol
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Port Number: 993
Service Name: imaps
Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: IMAP over TLS protocol
Reference: RFC XXXX (this document once published)
11.5. Submissions Port Registration 11.5. Submissions Port Registration
IANA is asked to assign an alternate usage of port 465 in addition to IANA is asked to assign an alternate usage of port 465 in addition to
the current assignment using the following template ([RFC6335]): the current assignment using the following template ([RFC6335]):
Service Name: submissions Service Name: submissions
Transport Protocol: TCP Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org> Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Description: Message Submission over TLS protocol Description: Message Submission over TLS protocol
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Port Number: 465
Service Name: submissions
Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: Message Submission over TLS protocol
Reference: RFC XXXX (this document once published)
This is a one time procedural exception to the rules in RFC 6335. This is a one time procedural exception to the rules in RFC 6335.
This requires explicit IESG approval and does not set a precedent. This requires explicit IESG approval and does not set a precedent.
Historically, port 465 was briefly registered as the "smtps" port. Historically, port 465 was briefly registered as the "smtps" port.
This registration made no sense as the SMTP transport MX This registration made no sense as the SMTP transport MX
infrastructure has no way to specify a port so port 25 is always infrastructure has no way to specify a port so port 25 is always
used. As a result, the registration was revoked and was subsequently used. As a result, the registration was revoked and was subsequently
reassigned to a different service. In hindsight, the "smtps" reassigned to a different service. In hindsight, the "smtps"
registration should have been renamed or reserved rather than registration should have been renamed or reserved rather than
revoked. Unfortunately, some widely deployed mail software revoked. Unfortunately, some widely deployed mail software
skipping to change at page 28, line 43 skipping to change at page 30, line 7
Description This code indicates an SMTP server was unable to forward Description This code indicates an SMTP server was unable to forward
a message to the next host necessary for delivery because it a message to the next host necessary for delivery because it
required a higher level of transport security or confidentiality required a higher level of transport security or confidentiality
than was available. The temporary form of this error is preferred than was available. The temporary form of this error is preferred
in case the problem is caused by a temporary administrative error in case the problem is caused by a temporary administrative error
such as an expired server certificate. such as an expired server certificate.
Reference This document Reference This document
Submitter C. Newman Submitter C. Newman
Change Controller IESG Change Controller IESG
11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 11.10. 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
skipping to change at page 29, line 45 skipping to change at page 31, line 10
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998. Mechanism", RFC 2449, November 1998.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, October [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971,
2000. October 2000.
[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, February 2002. Transport Layer Security", RFC 3207, February 2002.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January for Delivery Status Notifications", RFC 3464,
2003. January 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, January 2005.
[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, July 2007. Authentication Mechanism", RFC 5034, July 2007.
[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, November Accountability Requirements", BCP 134, RFC 5068,
2007. November 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248, June 2008. Mail System Status Codes", BCP 138, RFC 5248, June 2008.
skipping to change at page 31, line 13 skipping to change at page 32, line 25
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.ietf-uta-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-ietf-uta-email-tls- for Email Related Protocols",
certs-03 (work in progress), June 2015. draft-ietf-uta-email-tls-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, [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, May 2015. (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", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2246, January 1999. RFC 2595, June 1999.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
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.
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
Registration", RFC 3848, July 2004. Registration", RFC 3848, July 2004.
[RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887,
September 2004. September 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
for Authentication", RFC 4954, July 2007. for Authentication", RFC 4954, July 2007.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
2009. July 2009.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC 5804, July 2010. Managing Sieve Scripts", RFC 5804, July 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165,
6335, August 2011. RFC 6335, August 2011.
[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, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, November 2012.
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 draft-moore- The first version of this was written independently from
email-tls-00.txt; subsequent versions merge ideas from both drafts. draft-moore-email-tls-00.txt; subsequent versions merge ideas from
both drafts.
One author of this document was also the author of RFC 2595 that One author of this document was also the author of RFC 2595 that
became the standard for TLS usage with POP and IMAP, and the other became the standard for TLS usage with POP and IMAP, and the other
author was perhaps the first to propose that idea. In hindsight both author was perhaps the first to propose that idea. In hindsight both
authors now believe that that approach was a mistake. At this point authors now believe that that approach was a mistake. At this point
the authors believe that while anything that makes it easier to the authors believe that while anything that makes it easier to
deploy TLS is good, the desirable end state is that these protocols deploy TLS is good, the desirable end state is that these protocols
always use TLS, leaving no need for a separate port for cleartext always use TLS, leaving no need for a separate port for cleartext
operation except to support legacy clients while they continue to be operation except to support legacy clients while they continue to be
used. The separate port model for TLS is inherently simpler to used. The separate port model for TLS is inherently simpler to
skipping to change at page 33, line 30 skipping to change at page 34, line 43
security layers other than TLS in email is small enough to be security layers other than TLS in email is small enough to be
effectively irrelevant. The third bullet is incorrect because it effectively irrelevant. The third bullet is incorrect because it
misses the desirable option of "use and latch-on TLS if available". misses the desirable option of "use and latch-on TLS if available".
The fourth bullet may be correct, but is not a problem yet with The fourth bullet may be correct, but is not a problem yet with
current port consumption rates. The fundamental error was current port consumption rates. The fundamental error was
prioritizing a perceived better design based on a mostly valid prioritizing a perceived better design based on a mostly valid
critique over real-world deployability. But getting security and critique over real-world deployability. But getting security and
confidentiality facilities actually deployed is so important it confidentiality facilities actually deployed is so important it
should trump design purity considerations. should trump design purity considerations.
Appendix B. Open Issues Port 465 is presently used for two purposes: for submissions by a
large number of clients and service providers and for the "urd"
There are many open issues with this document. Here is an attempt to protocol by one vendor. Actually documenting this current state is
enumerate some of them: controversial as discussed in the IANA considerations section.
However, there is no good alternative. Registering a new port for
submissions when port 465 is widely used for that purpose already
will just create interoperability problems. Registering a port
that's only used if advertised by an SRV record (RFC 6186) would not
create interoperability problems but would require all client and
server deployments and software to change significantly which is
contrary to the goal of promoting more TLS use. Encouraging use of
STARTTLS on port 587 would not create interoperability problems, but
is unlikely to have impact on current undocumented use of port 465
and makes the guidance in this document less consistent. The
remaining option is to document the current state of the world and
support future use of port 465 for submission as this increases
consistency and ease-of-deployment for TLS email submission.
o Port 465 is presently used for two purposes: for submissions by a Appendix B. Change Log
large number of clients and service providers and for the "urd"
protocol by one vendor. Actually documenting this current state
is controversial as discussed in the IANA considerations section.
However, there is no good alternative. Registering a new port for
submissions when port 465 is widely used for that purpose already
will just create interoperability problems. Registering a port
that's only used if advertised by an SRV record (RFC 6186) would
not create interoperability problems but would require all client
and server deployments and software to change significantly which
is contrary to the goal of promoting more TLS use. Encouraging
use of STARTTLS on port 587 would not create interoperability
problems, but is unlikely to have impact on current undocumented
use of port 465 and makes the guidance in this document less
consistent.
o One author believes that the security latch model is complementary Changes since draft-ietf-uta-email-deep-01:
with draft-ietf-dane-smtp-with-dane-02 but hasn't thought about
the issues in depth. We welcome feedback on this point.
o The two authors of this document and the author of draft-melnikov- o Change text in tls11 and tls12 registrations to clarify
email-tls-certs are willing to merge these two documents. certificate rules, including additional PKIX and DANE references.
However, it is undesirable to delay publication of either document
so this will be done only if the latter document is not yet
through IESG processing when this document is ready for the IESG.
o It might make sense to split this in two or more documents if it's o Change from tls10 to tls11 (including reference) as the minimum.
getting too long to evaluate in one IETF last call. In
particular, it might make sense to put implementation requirements
and service provider requirements in separate documents. The
authors prefer to edit one document for now and defer discussion
of splitting the document until all technical issues are resolved.
o The use of SRV records [RFC6186] for account setup or refresh is o Fix typo in example 5.
presently not secure from DNS active attacks unless DNSSEC is
used. If someone wishes to provide suggested text describing how
to use DANE in this process, the WG can consider adding that text
to this document. Absent suggested text, the editor intends to
leave this issue alone.
Appendix C. Change Log o Remove open issues section; enough time has passed so not worth
waiting for more input.
Changes since draft-ietf-uta-email-deep-00: Changes since draft-ietf-uta-email-deep-00:
o Update and clarify abstract o Update and clarify abstract
o use term confidentiality instead of privacy in most cases. o use term confidentiality instead of privacy in most cases.
o update open issues to request input for missing text. o update open issues to request input for missing text.
o move certificate pinning sub-section to account setup section and o move certificate pinning sub-section to account setup section and
skipping to change at page 36, line 25 skipping to change at page 37, line 22
o Added reference to HSTS. o Added reference to HSTS.
Changes since -00: Changes since -00:
o Rewrote introduction to merge ideas from draft-moore-email-tls-00. o Rewrote introduction to merge ideas from draft-moore-email-tls-00.
o Added Implicit TLS section, Account configuration section and IANA o Added Implicit TLS section, Account configuration section and IANA
port registration updates based on draft-moore-email-tls-00. port registration updates based on draft-moore-email-tls-00.
o Add protocol details necessary to standardize implicit TLS for o Add protocol details necessary to standardize implicit TLS for
POP/IMAP/submission, using ideas from draft-melnikov-pop3-over- POP/IMAP/submission, using ideas from
tls. draft-melnikov-pop3-over-tls.
o Reduce initial set of security tags based on feedback. o Reduce initial set of security tags based on feedback.
o Add deep status concept to allow a window for software updates to o Add deep status concept to allow a window for software updates to
be backed out before latches make that problematic, as well as to be backed out before latches make that problematic, as well as to
provide service providers with a mechanism they can use to assist provide service providers with a mechanism they can use to assist
customers in the event of a privacy failure. customers in the event of a privacy failure.
o Add DNS SRV section from draft-moore-email-tls-00. o Add DNS SRV section from draft-moore-email-tls-00.
o Write most of the missing IANA considerations section. o Write most of the missing IANA considerations section.
o Rewrite most of implementation requirements section based more on o Rewrite most of implementation requirements section based more on
draft-moore-email-tls-00. Remove new cipher requirements for now draft-moore-email-tls-00. Remove new cipher requirements for now
because those may be dealt with elsewhere. because those may be dealt with elsewhere.
Appendix D. Acknowledgements Appendix C. Acknowledgements
Thanks to Ned Freed for discussion of the initial latch concepts in Thanks to Ned Freed for discussion of the initial latch concepts in
this document. Thanks to Alexey Melnikov for draft-melnikov-pop3- this document. Thanks to Alexey Melnikov for
over-tls-02, which was the basis of the POP3 implicit TLS text. draft-melnikov-pop3-over-tls-02, which was the basis of the POP3
Thanks to Russ Housley, Alexey Melnikov and Dan Newman for review implicit TLS text. Thanks to Russ Housley, Alexey Melnikov and Dan
feedback. Thanks to Paul Hoffman for interesting feedback in initial Newman for review feedback. Thanks to Paul Hoffman for interesting
conversations about this idea. feedback in initial 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. 48 change blocks. 
189 lines changed or deleted 192 lines changed or added

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