draft-ietf-uta-email-deep-10.txt   draft-ietf-uta-email-deep-11.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 October 26, 2017 Intended status: Standards Track November 25, 2017
Expires: April 29, 2018 Expires: May 29, 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-10 draft-ietf-uta-email-deep-11
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 April 29, 2018. This Internet-Draft will expire on May 29, 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 28 skipping to change at page 2, line 28
Message Submission Services . . . . . . . . . . . . . . . . . 6 Message Submission Services . . . . . . . . . . . . . . . . . 6
4.1. Deprecation of Services Using Cleartext and TLS Versions 4.1. Deprecation of Services Using Cleartext and TLS Versions
< 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 < 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Mail Server Use of Client Certificate Authentication . . 9 4.2. Mail Server Use of Client Certificate Authentication . . 9
4.3. Recording TLS Cipher Suite in Received Header . . . . . . 9 4.3. Recording TLS Cipher Suite in Received Header . . . . . . 9
4.4. TLS Server Certificate Requirements . . . . . . . . . . . 10 4.4. TLS Server Certificate Requirements . . . . . . . . . . . 10
4.5. Recommended DNS records for mail protocol servers . . . . 10 4.5. Recommended DNS records for mail protocol servers . . . . 10
4.5.1. MX records . . . . . . . . . . . . . . . . . . . . . 10 4.5.1. MX records . . . . . . . . . . . . . . . . . . . . . 10
4.5.2. SRV records . . . . . . . . . . . . . . . . . . . . . 10 4.5.2. SRV records . . . . . . . . . . . . . . . . . . . . . 10
4.5.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.4. TLSA records . . . . . . . . . . . . . . . . . . . . 10 4.5.4. TLSA records . . . . . . . . . . . . . . . . . . . . 11
4.6. Changes to Internet Facing Servers . . . . . . . . . . . 11 4.6. Changes to Internet Facing Servers . . . . . . . . . . . 11
5. Use of TLS by Mail User Agents . . . . . . . . . . . . . . . 11 5. Use of TLS by Mail User Agents . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . 17 7.3. Submissions Port Registration . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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
skipping to change at page 10, line 15 skipping to change at page 10, line 15
MSPs MUST maintain valid server certificates for all servers. See MSPs MUST maintain valid server certificates for all servers. See
[RFC7817] for the recommendations and requirements necessary to [RFC7817] for the recommendations and requirements necessary to
achieve this. achieve this.
If a protocol server provides service for more than one mail domain, If a protocol server provides service for more than one mail domain,
it MAY use a separate IP address for each domain and/or a server it MAY use a separate IP address for each domain and/or a server
certificate that advertises multiple domains. This will generally be certificate that advertises multiple domains. This will generally be
necessary unless and until it is acceptable to impose the constraint necessary unless and until it is acceptable to impose the constraint
that the server and all clients support the Server Name Indication that the server and all clients support the Server Name Indication
extension to TLS [RFC6066]. For more discussion of this problem, see extension to TLS [RFC6066]. Mail servers supporting SNI need to
support the post-SRV hostname to interoperate with MUAs that have not
implemented RFC 6186. For more discussion of this problem, see
section 5.1 of [RFC7817]. section 5.1 of [RFC7817].
4.5. Recommended DNS records for mail protocol servers 4.5. Recommended DNS records for mail protocol servers
This section discusses not only the DNS records that are recommended, This section discusses not only the DNS records that are recommended,
but also implications of DNS records for server configuration and TLS but also implications of DNS records for server configuration and TLS
server certificates. server certificates.
4.5.1. MX records 4.5.1. MX records
skipping to change at page 13, line 15 skipping to change at page 13, line 22
Similarly, a MUA MUST NOT attempt to "test" a particular mail account Similarly, a MUA MUST NOT attempt to "test" a particular mail account
configuration by submitting the user's authentication credentials to configuration by submitting the user's authentication credentials to
a server, unless a TLS session meeting minimum confidentiality levels a server, unless a TLS session meeting minimum confidentiality levels
has been established with that server. If minimum confidentiality has been established with that server. If minimum confidentiality
requirements have not been satisfied, the MUA must explicitly warn requirements have not been satisfied, the MUA must explicitly warn
the user that his password may be exposed to attackers before testing the user that his password may be exposed to attackers before testing
the new configuration. the new configuration.
When establishing a new configuration for connecting to an IMAP, POP, When establishing a new configuration for connecting to an IMAP, POP,
or SMTP submission server, based on SRV records, an MUA SHOULD either or SMTP submission server, based on SRV records, an MUA SHOULD either
verify that the SRV records are verifiability signed using DNSSEC, or verify that the SRV records are signed using DNSSEC, or that the
that the target FQDN of the SRV record matches the original server target FQDN of the SRV record matches the original server FQDN for
FQDN for which the SRV queries were made. If the target FQDN is not which the SRV queries were made. If the target FQDN is not in the
in the queried domain, the MUA SHOULD verify with the user that the queried domain, the MUA SHOULD verify with the user that the SRV
SRV target FQDN is suitable for use, before executing any connections target FQDN is suitable for use, before executing any connections to
to the host. (See [RFC6186] section 6). the host. (See [RFC6186] section 6).
An MUA MUST NOT consult SRV records to determine which servers to use An MUA MUST NOT consult SRV records to determine which servers to use
on every connection attempt, unless those SRV records are signed by on every connection attempt, unless those SRV records are signed by
DNSSEC and have a valid signature. However, an MUA MAY consult SRV DNSSEC and have a valid signature. However, an MUA MAY consult SRV
records from time to time to determine if an MSP's server 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.
 End of changes. 10 change blocks. 
17 lines changed or deleted 19 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/