draft-ietf-uta-email-deep-07.txt   draft-ietf-uta-email-deep-08.txt 
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Network Heretics Internet-Draft Windrock
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 3, 2017 Intended status: Standards Track July 21, 2017
Expires: January 4, 2018 Expires: January 22, 2018
Cleartext Considered Obsolete: Best Current Practices for Use of TLS for Cleartext Considered Obsolete: Use of TLS for Email Submission and
Email Submission and Access Access
draft-ietf-uta-email-deep-07 draft-ietf-uta-email-deep-08
Abstract Abstract
This specification outlines best current practices for use of This specification outlines current recommendations for 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
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 4, 2018. This Internet-Draft will expire on January 22, 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology Used in This Document . . . . . . 3 2. Conventions and Terminology Used in This Document . . . . . . 3
3. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Implicit TLS for POP . . . . . . . . . . . . . . . . . . 5 3.1. Implicit TLS for POP . . . . . . . . . . . . . . . . . . 5
3.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 5 3.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 5
3.3. Implicit TLS for SMTP Submission . . . . . . . . . . . . 5 3.3. Implicit TLS for SMTP Submission . . . . . . . . . . . . 5
3.4. Implicit TLS Connection Closure for POP, IMAP and SMTP 3.4. Implicit TLS Connection Closure for POP, IMAP and SMTP
Submission . . . . . . . . . . . . . . . . . . . . . . . 6 Submission . . . . . . . . . . . . . . . . . . . . . . . 6
4. Best Current Practices for Use of TLS by Mail Access 4. Recommendations for Use of TLS by Mail Access
Services and Message Submission Services . . . . . . . . . . 6 Services and 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 < 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Mail Server Use of Client Certificate Authentication . . 8 4.2. Mail Server Use of Client Certificate Authentication . . 8
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 . . . . . . . . . . . 9 4.4. TLS Server Certificate Requirements . . . . . . . . . . . 9
4.5. Recommended DNS records for mail protocol servers . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 10
4.6. Changes to Internet Facing Servers . . . . . . . . . . . 10 4.6. Changes to Internet Facing Servers . . . . . . . . . . . 10
5. Best Current Practices for use of TLS by Mail User Agents . . 10 5. Recommendations for use of TLS by Mail User Agents . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 14
5.5. Client Certificate Authentication . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. POP3S Port Registration Update . . . . . . . . . . . . . 15 7.1. POP3S Port Registration Update . . . . . . . . . . . . . 15
7.2. IMAPS Port Registration Update . . . . . . . . . . . . . 16 7.2. IMAPS Port Registration Update . . . . . . . . . . . . . 16
7.3. Submissions Port Registration . . . . . . . . . . . . . . 16 7.3. Submissions Port Registration . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Design Considerations . . . . . . . . . . . . . . . 20 Appendix A. Design Considerations . . . . . . . . . . . . . . . 20
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Software that provides email service via Internet Message Access Software that provides email service via Internet Message Access
Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] and/ Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] and/
or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually
has Transport Layer Security (TLS) [RFC5246] support but often does has Transport Layer Security (TLS) [RFC5246] support but often does
not use it in a way that maximizes end-user confidentiality. This not use it in a way that maximizes end-user confidentiality. This
specification describes best current practices for use of TLS in specification describes current recommendations for use of TLS in
interactions between Mail User Agents and Mail Access Services, and interactions between Mail User Agents and Mail Access Services, and
between Mail User Agents and Mail Submission Services. between Mail User Agents and Mail Submission Services.
In brief, this memo now recommends that: In brief, this memo now recommends that:
o TLS version 1.1 or greater be used for all traffic between mail o TLS version 1.2 or greater be used for all traffic between mail
user agents (MUAs) and mail submission servers, and also between user agents (MUAs) and mail submission servers, and also between
MUAs and mail access servers. MUAs and mail access servers.
o MUAs and mail service providers discourage use of cleartext o MUAs and mail service providers discourage use of cleartext
protocols for mail access and mail submission, and deprecate use protocols for mail access and mail submission, and deprecate use
of cleartext protocols for these purposes as soon as practicable. of cleartext protocols for these purposes as soon as practicable.
o Use of "Implicit TLS" on ports reserved for that purpose, in o Use of "Implicit TLS" on ports reserved for that purpose, in
preference to STARTTLS on a port that otherwise supports preference to STARTTLS on a port that otherwise supports
cleartext. cleartext.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
and SHOULD implement the certificate validation mechanism described and SHOULD implement the certificate validation mechanism described
in [RFC7817]. Once the TLS session is established, IMAP [RFC3501] in [RFC7817]. Once the TLS session is established, IMAP [RFC3501]
protocol messages are exchanged as TLS application data for the protocol messages are exchanged as TLS application data for the
remainder of the TCP connection. If client credentials were provided remainder of the TCP connection. If client credentials were provided
during the TLS handshake that the server finds acceptable, the server during the TLS handshake that the server finds acceptable, the server
MAY issue a PREAUTH greeting in which case both the server and client MAY issue a PREAUTH greeting in which case both the server and client
enter AUTHENTICATED state. If the server issues an OK greeting then enter AUTHENTICATED state. If the server issues an OK greeting then
both server and client enter NOT AUTHENTICATED state. both server and client enter NOT AUTHENTICATED state.
See Section 5.5 and Section 4.2 for additional information on client See Section 5.5 and Section 4.2 for additional information on client
certificate authentication. See Section 7.1 for port registration certificate authentication. See Section 7.1 and Section 7.2 for port
information. See Section 7.2 for port registration information. registration information.
3.3. Implicit TLS for SMTP Submission 3.3. Implicit TLS for SMTP Submission
When a TCP connection is established for the "submissions" service When a TCP connection is established for the "submissions" service
(default port 465), a TLS handshake begins immediately. Clients MUST (default port 465), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in implement the certificate validation mechanism described in
[RFC7817]. Once a TLS session is established, message submission [RFC7817]. Once a TLS session is established, message submission
protocol data [RFC6409] is exchanged as TLS application data for the protocol data [RFC6409] is exchanged as TLS application data for the
remainder of the TCP connection. (Note: the "submissions" service remainder of the TCP connection. (Note: the "submissions" service
name is defined in section 10.3 of this document, and follows the name is defined in section 10.3 of this document, and follows the
skipping to change at page 6, line 35 skipping to change at page 6, line 35
information. information.
3.4. Implicit TLS Connection Closure for POP, IMAP and SMTP Submission 3.4. Implicit TLS Connection Closure for POP, IMAP and SMTP Submission
When a client or server wishes to close the connection, it SHOULD When a client or server wishes to close the connection, it SHOULD
initiate the exchange of TLS close alerts before TCP connection initiate the exchange of TLS close alerts before TCP connection
termination. The client MAY, after sending a TLS close alert, termination. The client MAY, after sending a TLS close alert,
gracefully close the TCP connection without waiting for a TLS gracefully close the TCP connection without waiting for a TLS
response from the server. response from the server.
4. Best Current Practices for Use of TLS by Mail Access Services and 4. Recommendations for Use of TLS by Mail Access Services and Message
Message Submission Services Submission Services
The following practices are recommended for Mail Access Services and The following practices are recommended for Mail Access Services and
Mail Submission Services: Mail Submission Services:
o Mail Service Providers (MSPs) which support POP, IMAP, and/or o Mail Service Providers (MSPs) which support POP, IMAP, and/or
Message Submission, SHOULD provide and support instances of those Message Submission, MUST support TLS access for those services.
services which use Implicit TLS. (See Section 3.)
o Other services than POP, IMAP and/or Message Submission provided
by MSPs SHOULD support TLS access, and MUST support TLS access for
those services which support authentication via username and
password.
o MSPs which support POP, IMAP, and/or Message Submission, SHOULD
provide and support instances of those services which use Implicit
TLS. (See Section 3.)
o For compatibility with existing MUAs and existing MUA o For compatibility with existing MUAs and existing MUA
configurations, MSPs SHOULD also, in the near term, provide configurations, MSPs SHOULD also, in the near term, provide
instances of these services which support STARTTLS. This will instances of these services which support STARTTLS. This will
permit legacy MUAs to discover new availability of TLS capability permit legacy MUAs to discover new availability of TLS capability
on servers, and may increase use of TLS by such MUAs. However, on servers, and may increase use of TLS by such MUAs. However,
servers SHOULD NOT advertise STARTTLS if use of the STARTTLS servers SHOULD NOT advertise STARTTLS if use of the STARTTLS
command by a client is likely to fail (for example, if the server command by a client is likely to fail (for example, if the server
has no server certificate configured.) has no server certificate configured.)
o MSPs SHOULD advertise their Mail Access Services and Mail o MSPs SHOULD advertise their Mail Access Services and Mail
Submission Services using DNS SRV records according to [RFC6186]. Submission Services using DNS SRV records according to [RFC6186].
Services supporting TLS SHOULD be advertised in preference to (In addition to making correct configuration easier for MUAs, this
cleartext services (if offered). In addition, services using provides a way by which MUAs can discover when an MSP begins to
Implicit TLS SHOULD be advertised in preference to services offer TLS-based services.) Services supporting TLS SHOULD be
supporting STARTTLS (if offered). (See also Section 4.5.) advertised in preference to cleartext services (if offered). In
addition, services using Implicit TLS SHOULD be advertised in
preference to services supporting STARTTLS (if offered). (See
also Section 4.5.)
o MSPs SHOULD deprecate use of cleartext Mail Access Services and o MSPs SHOULD deprecate use of cleartext Mail Access Services and
Mail Submission Services as soon as practicable. (See Mail Submission Services as soon as practicable. (See
Section 4.1.) Section 4.1.)
o MSPs that provide mail submission as a service, SHOULD support
Mail Submission services using Implicit TLS.
o MSPs currently supporting such use of cleartext SMTP (on port 25) o MSPs currently supporting such use of cleartext SMTP (on port 25)
as a means of message submission by their users (whether or not as a means of message submission by their users (whether or not
requiring authentication) SHOULD transition their users to using requiring authentication) SHOULD transition their users to using
TLS (either Implicit TLS or STARTTLS) as soon as practicable. TLS (either Implicit TLS or STARTTLS) as soon as practicable.
o Mail services SHOULD support TLS 1.2 or later. o Mail services MUST support TLS 1.2 or later.
o All Mail services SHOULD implement the recommended TLS cipher o All Mail services SHOULD implement the recommended TLS cipher
suites described in [RFC7525] or a future BCP or standards track suites described in [RFC7525] or a future BCP or standards track
revision of that document. revision of that document.
o Mail services currently supporting SSL 2.x, SSL 3.0, or TLS 1.0 o Mail services currently supporting SSL 2.x, SSL 3.0, or TLS 1.0
SHOULD transition their users to later versions of TLS, and SHOULD transition their users to later versions of TLS, and
discontinue support for those versions of SSL and TLS, as soon as discontinue support for those versions of SSL and TLS, as soon as
practicable. practicable.
skipping to change at page 8, line 4 skipping to change at page 8, line 10
information along with any connection or authentication logs that information along with any connection or authentication logs that
they maintain. they maintain.
Additional considerations and details appear below. Additional considerations and details appear below.
4.1. Deprecation of Services Using Cleartext and TLS Versions < 1.1 4.1. Deprecation of Services Using Cleartext and TLS Versions < 1.1
The specific means employed for deprecation of cleartext Mail Access The specific means employed for deprecation of cleartext Mail Access
Services and Mail Submission Services this MAY vary from one MSP to Services and Mail Submission Services this MAY vary from one MSP to
the next in light of their user communities' needs and constraints. the next in light of their user communities' needs and constraints.
For example, an MSP MAY implement a gradual transition in which, over For example, an MSP MAY implement a gradual transition in which, over
time, more and more users are forbidden to authenticate to cleartext time, more and more users are forbidden to authenticate to cleartext
instances of these services, thus encouraging those users to migrate instances of these services, thus encouraging those users to migrate
to Implicit TLS. Access to cleartext services should eventually be to Implicit TLS. Access to cleartext services should eventually be
either disabled, or limited strictly for use by legacy systems which either disabled, or limited strictly for use by legacy systems which
cannot be upgraded. cannot be upgraded.
After a user's ability to authenticate to a service using cleartext After a user's ability to authenticate to a service using cleartext
is revoked, the server denying such access MUST NOT provide any is revoked, the server denying such access MUST NOT provide any
indication of whether the user's authentication credentials were indication over a cleartext channel of whether the user's
valid. An attempt to authenticate as such a user using either authentication credentials were valid. An attempt to authenticate as
invalid credentials or valid credentials MUST both result in the same such a user using either invalid credentials or valid credentials
indication of access being denied. MUST both result in the same indication of access being denied.
Also, users authenticating with passwords SHOULD be required to Also, users authenticating with passwords SHOULD be required to
change those passwords when migrating from cleartext to TLS, since change those passwords when migrating from cleartext to TLS, since
the old passwords were likely to have been compromised. the old passwords were likely to have been compromised.
Transition of users from SSL or TLS 1.0 to later versions of TLS MAY Transition of users from SSL or TLS 1.0 to later versions of TLS MAY
be accomplished by a means similar to that described above. There be accomplished by a means similar to that described above. There
are multiple ways to accomplish this. One way is for the server to are multiple ways to accomplish this. One way is for the server to
refuse a ClientHello message from any client sending a protocol refuse a ClientHello message from any client sending a protocol
version number corresponding to any version of SSL or TLS 1.0. version number corresponding to any version of SSL or TLS 1.0.
skipping to change at page 10, line 41 skipping to change at page 10, line 47
DNSSEC. DNSSEC.
4.6. Changes to Internet Facing Servers 4.6. Changes to Internet Facing Servers
When an MSP changes the Internet Facing Servers providing mail access When an MSP changes the Internet Facing Servers providing mail access
and mail submission services, including SMTP-based spam/virus and mail submission services, including SMTP-based spam/virus
filters, it is generally necessary to support the same and/or a newer filters, it is generally necessary to support the same and/or a newer
version of TLS and the same security directives that were previously version of TLS and the same security directives that were previously
advertised. advertised.
5. Best Current Practices for use of TLS by Mail User Agents 5. Recommendations for use of TLS by Mail User Agents
It is recommended that Mail User Agents implement the following It is recommended that Mail User Agents implement the following
practices: practices:
o MUAs SHOULD be capable of using DNS SRV records to discover Mail o MUAs SHOULD be capable of using DNS SRV records to discover Mail
Access Services and Mail Submission Services that are advertised Access Services and Mail Submission Services that are advertised
by a MSP for an account being configured. Other means of by a MSP for an account being configured. Other means of
discovering server configuration information (e.g. a database discovering server configuration information (e.g. a database
maintained by the MUA vendor) MAY also be supported. (See maintained by the MUA vendor) MAY also be supported. (See
Section 5.1 for more information.) Section 5.1 for more information.)
skipping to change at page 11, line 33 skipping to change at page 11, line 40
times and locations in order to inform the user of the times and locations in order to inform the user of the
confidentiality of the communications associated with that confidentiality of the communications associated with that
account. For example, this might be done whenever (a) prompting account. For example, this might be done whenever (a) prompting
the user for authentication credentials, (b) the user is composing the user for authentication credentials, (b) the user is composing
mail that will be sent to a particular submission server, (c) a mail that will be sent to a particular submission server, (c) a
list of accounts is displayed (particularly if the user can select list of accounts is displayed (particularly if the user can select
from that list to read mail), or (d) the user is requesting to from that list to read mail), or (d) the user is requesting to
view or update any configuration data that will be stored on a view or update any configuration data that will be stored on a
remote server. remote server.
o MUAs SHOULD implement TLS 1.2 or later. Earlier TLS and SSL o MUAs MUST implement TLS 1.2 [RFC5246] or later. Earlier TLS and
versions MAY also be supported so long as the MUA requires at SSL versions MAY also be supported so long as the MUA requires at
least TLS 1.1 when accessing accounts that are configured to least TLS 1.1 [RFC4346] when accessing accounts that are
impose minimum confidentiality requirements. configured to impose minimum confidentiality requirements. Per
[RFC7525], TLS 1.1 (or earlier) SHOULD NOT be used unless no
higher version is available during TLS protocol negotiation.
o All MUAs SHOULD implement the recommended TLS cipher suites o All MUAs SHOULD implement the recommended TLS cipher suites
described in [RFC7525] or a future BCP or standards track revision described in [RFC7525] or a future BCP or standards track revision
of that document. of that document.
o MUAs that are configured to not require minimum confidentiality o MUAs that are configured to not require minimum confidentiality
for one or more accounts SHOULD detect when TLS becomes available for one or more accounts SHOULD detect when TLS becomes available
on those accounts, and offer to upgrade the account to impose on those accounts (using [RFC6186] or other means), and offer to
minimum confidentiality requirements. upgrade the account to require TLS.
Additional considerations and details appear below. Additional considerations and details appear below.
5.1. Use of SRV records in Establishing Configuration 5.1. Use of SRV records in Establishing Configuration
This section updates [RFC6186] by changing the preference rules and This section updates [RFC6186] by changing the preference rules and
adding a new SRV service label _submissions._tcp to refer to Message adding a new SRV service label _submissions._tcp to refer to Message
Submission with Implicit TLS. Submission with Implicit TLS.
User-configurable MUAs SHOULD support use of [RFC6186] for account User-configurable MUAs SHOULD support use of [RFC6186] for account
skipping to change at page 12, line 42 skipping to change at page 12, line 46
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, an MUA SHOULD NOT blindly trust SRV or SMTP submission server, based on SRV records, an MUA SHOULD either
records unless they are signed by DNSSEC and have a valid signature. verify that the SRV records are verifiably signed using DNSSEC, or
Instead, the MUA SHOULD warn the user that the DNS-advertised that the target FQDN of the SRV record matches the original server
mechanism for connecting to the server is not authenticated, and FQDN for which the SRV queries were made. If the target FQDN is not
request the user to manually verify the connection details by in the queried domain, the MUA SHOULD verify with the user that the
reference to his or her mail service provider's documentation. SRV target FQDN is suitable for use, before executing any connections
to the host. (See [RFC6186] section 6).
Similarly, an MUA MUST NOT consult SRV records to determine which An MUA MUST NOT consult SRV records to determine which servers to use
servers to use on every connection attempt, unless those SRV records on every connection attempt, unless those SRV records are signed by
are signed by DNSSEC and have a valid signature. However, an MUA MAY DNSSEC and have a valid signature. However, an MUA MAY consult SRV
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.
5.2. Minimum Confidentiality Level 5.2. Minimum Confidentiality Level
MUAs SHOULD, by default, require a minimum level of confidentiality MUAs SHOULD, by default, require a minimum level of confidentiality
for services accessed by each account. For MUAs supporting the for services accessed by each account. For MUAs supporting the
ability to access multiple mail accounts, this requirement SHOULD be ability to access multiple mail accounts, this requirement SHOULD be
skipping to change at page 19, line 19 skipping to change at page 19, line 30
<http://www.rfc-editor.org/info/rfc2595>. <http://www.rfc-editor.org/info/rfc2595>.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet [RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
<http://www.rfc-editor.org/info/rfc2979>. <http://www.rfc-editor.org/info/rfc2979>.
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004,
<http://www.rfc-editor.org/info/rfc3848>. <http://www.rfc-editor.org/info/rfc3848>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>.
[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,
<http://www.rfc-editor.org/info/rfc4422>. <http://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,
<http://www.rfc-editor.org/info/rfc4954>. <http://www.rfc-editor.org/info/rfc4954>.
skipping to change at page 21, line 27 skipping to change at page 21, line 45
contrary to the goal of promoting more TLS use. Encouraging use of contrary to the goal of promoting more TLS use. Encouraging use of
STARTTLS on port 587 would not create interoperability problems, but STARTTLS on port 587 would not create interoperability problems, but
is unlikely to have impact on current undocumented use of port 465 is unlikely to have impact on current undocumented use of port 465
and makes the guidance in this document less consistent. The and makes the guidance in this document less consistent. The
remaining option is to document the current state of the world and remaining option is to document the current state of the world and
support future use of port 465 for submission as this increases support future use of port 465 for submission as this increases
consistency and ease-of-deployment for TLS email submission. consistency and ease-of-deployment for TLS email submission.
Appendix B. Change Log Appendix B. Change Log
Changes since draft-ietf-uta-email-deep-07:
o After discussion with the WG in Prague, removed BCP language and
once again made unambiguous that this is intended as a standards-
track document.
o Server implementations now MUST implement TLS 1.2, consistent with
RFC 7525. MUAs may still consider a TLS 1.1 session as meeting
minimum confidentiality requirements.
o MSPs now MUST support TLS for POP, IMAP, Submission, and any other
services that use username/password authentication.
o Added text to clarify the purpose of recommending that MSPs use
DNS SRV records to advertise services.
o Changed text about MUAs not blindly trusting unsigned SRV records,
to instead restate RFC 6186 requirements.
Changes since draft-ietf-uta-email-deep-06: Changes since draft-ietf-uta-email-deep-06:
o On the recommendation of one of the co-chairs and some working o On the recommendation of one of the co-chairs and some working
group members, rewrote document with the intended status of BCP. group members, rewrote document with the intended status of BCP.
This involved removing a great deal of text that consisted This involved removing a great deal of text that consisted
essentially of new protocol specification, especially the STS essentially of new protocol specification, especially the STS
features, on the theory that a BCP should base its recommendations features, on the theory that a BCP should base its recommendations
on current practice, and that new protocol features should be on current practice, and that new protocol features should be
subject to the interoperability test requirements associated with subject to the interoperability test requirements associated with
normal standards-track documents. normal standards-track documents.
skipping to change at page 26, line 45 skipping to change at page 27, line 39
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 draft-melnikov-pop3-
over-tls-02, which was the basis of the POP3 Implicit TLS text. over-tls-02, which was the basis of the POP3 Implicit TLS text.
Thanks to Russ Housley, Alexey Melnikov and Dan Newman for review Thanks to Russ Housley, Alexey Melnikov and Dan Newman for review
feedback. Thanks to Paul Hoffman for interesting feedback in initial feedback. Thanks to Paul Hoffman for interesting feedback in initial
conversations about this idea. conversations about this idea.
Authors' Addresses Authors' Addresses
Keith Moore Keith Moore
Network Heretics Windrock
PO Box 1934 PO Box 1934
Knoxville, TN 37901 Knoxville, TN 37901
US US
Email: moore@network-heretics.com Email: moore@network-heretics.com
Chris Newman Chris Newman
Oracle Oracle
440 E. Huntington Dr., Suite 400 440 E. Huntington Dr., Suite 400
Arcadia, CA 91006 Arcadia, CA 91006
US US
 End of changes. 29 change blocks. 
54 lines changed or deleted 88 lines changed or added

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