draft-ietf-uta-email-deep-11.txt   draft-ietf-uta-email-deep-12.txt 
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Windrock, Inc. Internet-Draft Windrock, Inc.
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 November 25, 2017 Intended status: Standards Track December 6, 2017
Expires: May 29, 2018 Expires: June 9, 2018
Cleartext Considered Obsolete: Use of TLS for Email Submission and Cleartext Considered Obsolete: Use of TLS for Email Submission and
Access Access
draft-ietf-uta-email-deep-11 draft-ietf-uta-email-deep-12
Abstract Abstract
This specification outlines current recommendations for the use of This specification outlines current recommendations for the use of
Transport Layer Security (TLS) to provide confidentiality of email Transport Layer Security (TLS) to provide confidentiality of email
traffic between a mail user agent (MUA) and a mail submission or mail traffic between a mail user agent (MUA) and a mail submission or mail
access server. access server.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 29, 2018. This Internet-Draft will expire on June 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 41 skipping to change at page 2, line 41
5.1. Use of SRV records in Establishing Configuration . . . . 12 5.1. Use of SRV records in Establishing Configuration . . . . 12
5.2. Minimum Confidentiality Level . . . . . . . . . . . . . . 13 5.2. Minimum Confidentiality Level . . . . . . . . . . . . . . 13
5.3. Certificiate Validation . . . . . . . . . . . . . . . . . 14 5.3. Certificiate Validation . . . . . . . . . . . . . . . . . 14
5.4. Certificate Pinning . . . . . . . . . . . . . . . . . . . 15 5.4. Certificate Pinning . . . . . . . . . . . . . . . . . . . 15
5.5. Client Certificate Authentication . . . . . . . . . . . . 15 5.5. Client Certificate Authentication . . . . . . . . . . . . 15
6. Considerations related to Anti-Virus/Anti-Spam Software and 6. Considerations related to Anti-Virus/Anti-Spam Software and
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. POP3S Port Registration Update . . . . . . . . . . . . . 17 7.1. POP3S Port Registration Update . . . . . . . . . . . . . 17
7.2. IMAPS Port Registration Update . . . . . . . . . . . . . 17 7.2. IMAPS Port Registration Update . . . . . . . . . . . . . 17
7.3. Submissions Port Registration . . . . . . . . . . . . . . 18 7.3. Submissions Port Registration . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.4. Additional registered clauses for Received fields . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Design Considerations . . . . . . . . . . . . . . . 22 Appendix A. Design Considerations . . . . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
skipping to change at page 3, line 45 skipping to change at page 3, line 45
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.
2. Conventions and Terminology Used in This Document 2. Conventions and Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The term "Implicit TLS" refers to the automatic negotiation of TLS The term "Implicit TLS" refers to the automatic negotiation of TLS
whenever a TCP connection is made on a particular TCP port that is whenever a TCP connection is made on a particular TCP port that is
used exclusively by that server for TLS connections. The term used exclusively by that server for TLS connections. The term
"Implicit TLS" is intended to contrast with use of STARTTLS and "Implicit TLS" is intended to contrast with use of STARTTLS and
similar commands in POP, IMAP, SMTP message submission, and other similar commands in POP, IMAP, SMTP message submission, and other
protocols, that are used by client and server to explicitly negotiate protocols, that are used by client and server to explicitly negotiate
TLS on an established cleartext TCP connection. TLS on an established cleartext TCP connection.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
a Received header field for a message received via TLS. The value a Received header field for a message received via TLS. The value
included in this additional clause SHOULD be the registered cipher included in this additional clause SHOULD be the registered cipher
suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) included in suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) included in
the TLS cipher suite registry. In the event the implementation does the TLS cipher suite registry. In the event the implementation does
not know the name of the cipher suite (a situation that should be not know the name of the cipher suite (a situation that should be
remedied promptly), a four-digit hexadecimal cipher suite identifier remedied promptly), a four-digit hexadecimal cipher suite identifier
MAY be used. In addition, the Diffie-Hellman group name associated MAY be used. In addition, the Diffie-Hellman group name associated
with the ciphersuite MAY be included (when applicable and known) with the ciphersuite MAY be included (when applicable and known)
following the ciphersuite name. The ABNF for the field follows: following the ciphersuite name. The ABNF for the field follows:
tls-cipher-clause = CFWS "tls" FWS tls-cipher [ FWS "group" FWS dh-group ] tls-cipher-clause = CFWS "tls" FWS tls-cipher [ CFWS "group" FWS dh-group ]
tls-cipher = tls-cipher-name / tls-cipher-hex tls-cipher = tls-cipher-name / tls-cipher-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
dh-group = ALPHA *(ALPHA / DIGIT / "_" / "-") dh-group = ALPHA *(ALPHA / DIGIT / "_" / "-")
; as registered in IANA TLS Supported Groups Registry ; as registered in IANA TLS Supported Groups Registry
skipping to change at page 17, line 7 skipping to change at page 17, line 7
assessment. Furthermore, while a minimum confidentiality level can assessment. Furthermore, while a minimum confidentiality level can
prevent a man-in-the-middle from introducing spam or virus content prevent a man-in-the-middle from introducing spam or virus content
between the MUA and Submission server, it does not prevent other between the MUA and Submission server, it does not prevent other
forms of client or account compromise. Use of AVAS services for forms of client or account compromise. Use of AVAS services for
submitted email therefore remains necessary. submitted email therefore remains necessary.
7. IANA Considerations 7. IANA Considerations
7.1. POP3S Port Registration Update 7.1. POP3S Port Registration Update
IANA is asked to update the registration of the TCP well-known port IANA is asked to update the registration of the TCP well-known port
995, and also UDP well-known port 995, using the following templates 995 using the following template ([RFC6335]):
([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 Port Number: 995
Service Name: pop3s
Transport Protocol: UDP
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: POP3 over TLS protocol
Reference: RFC XXXX (this document once published)
Port Number: 995
7.2. IMAPS Port Registration Update 7.2. 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, and also UDP well-known port 993, using the following templates 993 using the following templates ([RFC6335]):
([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 Port Number: 993
Service Name: imaps No changes to existing UDP port assignments for pop3s or imaps are
Transport Protocol: UDP being requested.
Assignee: IETF <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Description: IMAP over TLS protocol
Reference: RFC XXXX (this document once published)
Port Number: 993
Note: the updates to the UDP port assignments preserve the pre-
existing alignment in which both TCP and UDP ports were allocated to
the same protocols (in this case POP3+TLS and IMAP4+TLS) even though
there is no specification for using either protocol over UDP. This
seems undesirable as it wastes UDP port assignments. However, it is
not within the scope of this document to revisit old conventions for
port assignments.
7.3. Submissions Port Registration 7.3. Submissions Port Registration
IANA is asked to assign an alternate usage of TCP port 465 in IANA is asked to assign an alternate usage of TCP port 465 in
addition to the current assignment using the following template addition to the current assignment using the following template
([RFC6335]): ([RFC6335]):
Service Name: submissions Service Name: submissions
Transport Protocol: TCP Transport Protocol: TCP
Assignee: IETF <iesg@ietf.org> Assignee: IETF <iesg@ietf.org>
skipping to change at page 19, line 5 skipping to change at page 18, line 27
service, email software will either continue with unregistered use of service, email software will either continue with unregistered use of
port 465 (leaving the port registry inaccurate relative to de-facto port 465 (leaving the port registry inaccurate relative to de-facto
practice and wasting a well-known port), or confusion between the de- practice and wasting a well-known port), or confusion between the de-
facto and registered ports will cause harmful interoperability facto and registered ports will cause harmful interoperability
problems that will deter use of TLS for message submission. The problems that will deter use of TLS for message submission. The
authors believe both of these outcomes are less desirable than a wart authors believe both of these outcomes are less desirable than a wart
in the registry documenting real-world usage of a port for two in the registry documenting real-world usage of a port for two
purposes. Although STARTTLS-on-port-587 has deployed, it has not purposes. Although STARTTLS-on-port-587 has deployed, it has not
replaced deployed use of Implicit TLS submission on port 465. replaced deployed use of Implicit TLS submission on port 465.
7.4. Additional registered clauses for Received fields
Per the provisions in [RFC5321], IANA is requested to add two
additional-registered-clauses for Received fields as defined in
Section 4.3 of this document:
o "tls" indicating the TLS cipher used (if applicable), and
o "group" indicating the Diffie-Hellman group used with the TLS
cipher (if applicable)
The descriptions and syntax of these additional clauses are in
Section 4.3 of this document.
8. Security Considerations 8. Security Considerations
This entire document is about security considerations. In general, This entire document is about security considerations. In general,
this is targeted to improve mail confidentiality and to mitigate this is targeted to improve mail confidentiality and to mitigate
threats external to the email system such as network-level snooping threats external to the email system such as network-level snooping
or interception; this is not intended to mitigate active attackers or interception; this is not intended to mitigate active attackers
who have compromised service provider systems. who have compromised service provider systems.
Implementers should be aware that use of client certificates with TLS Implementers should be aware that use of client certificates with TLS
1.2 reveals the user's identity to any party with ability to read 1.2 reveals the user's identity to any party with ability to read
skipping to change at page 22, line 15 skipping to change at page 21, line 50
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006, DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>. <https://www.rfc-editor.org/info/rfc4422>.
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954, Extension for Authentication", RFC 4954,
DOI 10.17487/RFC4954, July 2007, DOI 10.17487/RFC4954, July 2007,
<https://www.rfc-editor.org/info/rfc4954>. <https://www.rfc-editor.org/info/rfc4954>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
skipping to change at page 22, line 38 skipping to change at page 22, line 28
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/info/rfc7469>. 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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 draft-moore-
email-tls-00.txt; subsequent versions merge ideas from both drafts. 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
 End of changes. 13 change blocks. 
35 lines changed or deleted 35 lines changed or added

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