< draft-ietf-uta-email-deep-08.txt   draft-ietf-uta-email-deep-09.txt >
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Windrock 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 July 21, 2017 Intended status: Standards Track September 12, 2017
Expires: January 22, 2018 Expires: March 16, 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-08 draft-ietf-uta-email-deep-09
Abstract Abstract
This specification outlines current recommendations 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 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 January 22, 2018. This Internet-Draft will expire on March 16, 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 (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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.6. Changes to Internet Facing Servers . . . . . . . . . . . 10 4.6. Changes to Internet Facing Servers . . . . . . . . . . . 10
5. Recommendations 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 . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. POP3S Port Registration Update . . . . . . . . . . . . . 15 7.1. POP3S Port Registration Update . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 27 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 33 skipping to change at page 3, line 33
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.
This memo does not address use of TLS with SMTP for message relay This memo does not address use of TLS with SMTP for message relay
(where Message Submission [RFC6409] does not apply). Improved use of (where Message Submission [RFC6409] does not apply). Improved use of
TLS with SMTP for message relay requires a different approach. One TLS with SMTP for message relay requires a different approach. One
approach to address that topic is described in [RFC7672]. approach to address that topic is described in [RFC7672]; another is
in [I-D.ietf-uta-mta-sts].
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 8, line 8 skipping to change at page 8, line 8
o All Mail services implementing TLS SHOULD log TLS cipher o All Mail services implementing TLS SHOULD log TLS cipher
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 MAY vary from one MSP to the
the next in light of their user communities' needs and constraints. next in light of their user communities' needs and constraints. For
For example, an MSP MAY implement a gradual transition in which, over 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 over a cleartext channel of whether the user's indication over a cleartext channel of whether the user's
authentication credentials were valid. An attempt to authenticate as authentication credentials were valid. An attempt to authenticate as
such a user using either invalid credentials or valid credentials such a user using either invalid credentials or valid credentials
MUST both result in the same 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 previously authenticating with passwords sent as
change those passwords when migrating from cleartext to TLS, since cleartext SHOULD be required to change those passwords when migrating
the old passwords were likely to have been compromised. to TLS, since 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.
Another way is for the server to accept ClientHello messages from Another way is for the server to accept ClientHello messages from
some client versions that it does not wish to support, but later some client versions that it does not wish to support, but later
refuse to allow the user to authenticate. The latter method may refuse to allow the user to authenticate. The latter method may
provide a better indication to the user of the reason for the failure provide a better indication to the user of the reason for the failure
skipping to change at page 13, line 42 skipping to change at page 13, line 42
editing an account configuration, but MUST warn users that such a editing an account configuration, but MUST warn users that such a
configuration will not assure privacy for either passwords or configuration will not assure privacy for either passwords or
messages. messages.
An MUA which is configured to require a minimum level of An MUA which is configured to require a minimum level of
confidentiality for a mail account MUST NOT attempt to perform any confidentiality for a mail account MUST NOT attempt to perform any
operation other than capability discovery, or STARTTLS for servers operation other than capability discovery, or STARTTLS for servers
not using Implicit TLS, unless the minimum level of confidentiality not using Implicit TLS, unless the minimum level of confidentiality
is provided by that connection. is provided by that connection.
MUAs SHOULD NOT allow users to "click through" to access or send mail MUAs SHOULD NOT allow users to easily access or send mail via an
via an connection, or to authenticate to any service using a connection, or authenticate to any service using a password, if that
password, if that account is configured to impose minimum account is configured to impose minimum confidentiality requirements
confidentiality requirements and that connection does not meet all of and that connection does not meet all of those requirements. An
those requirements. Experience indicates that users presented with example of "easily access" would be to display a dialog informing the
such an option often "click through" without understanding the risks user that the security requirements of the account were not met by
that they're accepting by doing so. Furthermore, users who the connecting, but allowing the user to "click through" to send mail
frequently find the need to "click through" to use an insecure or access the service anyway. Experience indicates that users
connection may become conditioned to do so as a matter of habit, presented with such an option often "click through" without
before considering whether the risks are reasonable in each specific understanding the risks that they're accepting by doing so.
instance.
Furthermore, users who frequently find the need to "click through" to
use an insecure connection may become conditioned to do so as a
matter of habit, before considering whether the risks are reasonable
in each specific instance.
An MUA which is not configured to require a minimum level of An MUA which is not configured to require a minimum level of
confidentiality for a mail account SHOULD still attempt to connect to confidentiality for a mail account SHOULD still attempt to connect to
the services associated with that account using the most secure means the services associated with that account using the most secure means
available, e.g. by using Implicit TLS or STARTTLS. available, e.g. by using Implicit TLS or STARTTLS.
5.3. Certificiate Validation 5.3. Certificiate Validation
MUAs MUST validate TLS server certificates according to [RFC7817] and MUAs MUST validate TLS server certificates according to [RFC7817] and
PKIX [RFC5280]. PKIX [RFC5280].
skipping to change at page 14, line 45 skipping to change at page 14, line 48
server, for use when accessing that account's servers. This is server, for use when accessing that account's servers. This is
called certificate pinning. called certificate pinning.
Certificate pinning is only appropriate during mail account setup and Certificate pinning is only appropriate during mail account setup and
MUST NOT be offered as an option in response to a failed certificate MUST NOT be offered as an option in response to a failed certificate
validation for an existing mail account. An MUA that allows validation for an existing mail account. An MUA that allows
certificate pinning MUST NOT allow a certificate pinned for one certificate pinning MUST NOT allow a certificate pinned for one
account to validate connections for other accounts. account to validate connections for other accounts.
A pinned certificate is subject to a man-in-the-middle attack at A pinned certificate is subject to a man-in-the-middle attack at
account setup time, and lacks a mechanism to revoke or securely account setup time, and typically lacks a mechanism to automatically
refresh the certificate. Note also that a man-in-the-middle attack revoke or securely refresh the certificate. Note also that a man-in-
at account setup time will expose the user's password to the attacker the-middle attack at account setup time will expose the user's
(if a password is used). Therefore use of a pinned certificate does password to the attacker (if a password is used). Therefore use of a
not meet the requirement for a minimum confidentiality level, and an pinned certificate does not meet the requirement for a minimum
MUA MUST NOT indicate to the user that the such confidentiality is confidentiality level, and an MUA MUST NOT indicate to the user that
provided. Additional advice on certificate pinning is present in the such confidentiality is provided. Additional advice on
[RFC6125]. certificate pinning is present in [RFC6125].
5.5. Client Certificate Authentication 5.5. Client Certificate Authentication
MUAs MAY implement client certificate authentication on the Implicit MUAs MAY implement client certificate authentication on the Implicit
TLS port. An MUA MUST NOT provide a client certificate during the TLS port. An MUA MUST NOT provide a client certificate during the
TLS handshake unless the server requests one and the client has TLS handshake unless the server requests one and the client has
determined the certificate can be safely used with that specific determined the certificate can be safely used with that specific
server, OR the client has been explicitly configured by the user to server, OR the client has been explicitly configured by the user to
use that particular certificate with that server. How to make this use that particular certificate with that server. How to make this
determination is presently implementation specific. determination is presently implementation specific.
skipping to change at page 17, line 21 skipping to change at page 17, line 26
replaced deployed use of Implicit TLS submission on port 465. replaced deployed use of Implicit TLS submission on port 465.
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.
It could be argued that sharing the name and version of the client
software with the server has privacy implications. Although
providing this information is not required, it is encouraged so that
mail service providers can more effectively inform end-users running
old clients that they need to upgrade to protect their security, or
know which clients to use in a test deployment prior to upgrading a
server to have higher security requirements.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<http://www.rfc-editor.org/info/rfc1939>. <https://www.rfc-editor.org/info/rfc1939>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC3207, Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <http://www.rfc-editor.org/info/rfc3207>. February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[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, DOI 10.17487/RFC5034, Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034,
July 2007, <http://www.rfc-editor.org/info/rfc5034>. July 2007, <https://www.rfc-editor.org/info/rfc5034>.
[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, Accountability Requirements", BCP 134, RFC 5068,
DOI 10.17487/RFC5068, November 2007, DOI 10.17487/RFC5068, November 2007,
<http://www.rfc-editor.org/info/rfc5068>. <https://www.rfc-editor.org/info/rfc5068>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[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, Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011, DOI 10.17487/RFC6186, March 2011,
<http://www.rfc-editor.org/info/rfc6186>. <https://www.rfc-editor.org/info/rfc6186>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<http://www.rfc-editor.org/info/rfc6409>. <https://www.rfc-editor.org/info/rfc6409>.
[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, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, (DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <https://www.rfc-editor.org/info/rfc7672>.
[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
Server Identity Check Procedure for Email-Related Server Identity Check Procedure for Email-Related
Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
<http://www.rfc-editor.org/info/rfc7817>. <https://www.rfc-editor.org/info/rfc7817>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-uta-mta-sts]
Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
and J. Jones, "SMTP MTA Strict Transport Security (MTA-
STS)", draft-ietf-uta-mta-sts-09 (work in progress),
September 2017.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999, RFC 2595, DOI 10.17487/RFC2595, June 1999,
<http://www.rfc-editor.org/info/rfc2595>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc3848>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, (TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006, DOI 10.17487/RFC4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>. <https://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>. <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,
<http://www.rfc-editor.org/info/rfc4954>. <https://www.rfc-editor.org/info/rfc4954>.
[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,
<http://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
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[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, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[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, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
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
skipping to change at page 27, line 39 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
Windrock Windrock, Inc.
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. 40 change blocks. 
68 lines changed or deleted 71 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/