draft-ietf-uta-email-deep-02.txt   draft-ietf-uta-email-deep-03.txt 
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Network Heretics Internet-Draft Network Heretics
Updates: 1939, 2595, 3464, 3501, 5068, C. Newman Updates: 1939, 2595, 3464, 3501, 5068, C. Newman
6186, 6409 (if approved) Oracle 6186, 6409 (if approved) Oracle
Intended status: Standards Track March 10, 2016 Intended status: Standards Track March 11, 2016
Expires: September 11, 2016 Expires: September 12, 2016
Deployable Enhanced Email Privacy (DEEP) Deployable Enhanced Email Privacy (DEEP)
draft-ietf-uta-email-deep-02.txt draft-ietf-uta-email-deep-03.txt
Abstract Abstract
This specification defines a set of requirements and facilities This specification defines a set of requirements and facilities
designed to improve email confidentiality between a mail user agent designed to improve email confidentiality between a mail user agent
(MUA) and a mail submission or mail access server. This provides (MUA) and a mail submission or mail access server. This provides
mechanisms intended to increase use of already deployed Transport mechanisms intended to increase use of already deployed Transport
Layer Security (TLS) technology, provide a model for mail user Layer Security (TLS) technology, provide a model for mail user
agent's confidentiality assurance, and enable mail service providers agent's confidentiality assurance, and enable mail service providers
to advertise improved TLS confidentiality facilities. to advertise improved TLS confidentiality facilities.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 11, 2016. This Internet-Draft will expire on September 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 25 skipping to change at page 3, line 25
11.5. Submissions Port Registration . . . . . . . . . . . . . . 28 11.5. Submissions Port Registration . . . . . . . . . . . . . . 28
11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 28 11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 28
11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 29 11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 29
11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 29 11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 29
11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . . 29 11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . . 29
11.10. MAIL Parameters Additional-registered-clauses 11.10. MAIL Parameters Additional-registered-clauses
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 30 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Design Considerations . . . . . . . . . . . . . . . . 33 Appendix A. Design Considerations . . . . . . . . . . . . . . . . 34
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 37 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
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] Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939]
and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409]
usually has Transport Layer Security (TLS) [RFC5246] support but usually has Transport Layer Security (TLS) [RFC5246] support but
often does not use it in a way that maximizes end-user often does not use it in a way that maximizes end-user
confidentiality. This specification proposes changes to email confidentiality. This specification proposes changes to email
software and deployments intended to increase the use of TLS and software and deployments intended to increase the use of TLS and
skipping to change at page 4, line 32 skipping to change at page 4, line 32
o TLS on a well-known port ("Implicit TLS") be supported for IMAP, o TLS on a well-known port ("Implicit TLS") be supported for IMAP,
POP, and SMTP Submission [RFC6409] for all electronic mail user POP, and SMTP Submission [RFC6409] for all electronic mail user
agents (MUAs), servers, and service providers; agents (MUAs), servers, and service providers;
o MUAs and mail protocol servers cooperate (via mechanisms defined o MUAs and mail protocol servers cooperate (via mechanisms defined
in this specification) to upgrade security feature use and record/ in this specification) to upgrade security feature use and record/
indicate that usage appropriately. indicate that usage appropriately.
This does not address use of TLS with SMTP for message relay (where This does not address use of TLS with SMTP for message relay (where
Message Submission [RFC6409] does not apply). Improved use of TLS Message Submission [RFC6409] does not apply). Improved use of TLS
with SMTP for message relay requires a different approach. Future with SMTP for message relay requires a different approach. One
work may address that topic and one approach is described in approach to address that topic is described in [RFC7672].
[I-D.ietf-dane-smtp-with-dane].
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.
This draft is subject to change. Implementation of this proposal is This draft is subject to change. Implementation of this proposal is
not recommended at this time. Please discuss this proposal on the not recommended at this time. Please discuss this proposal on the
ietf-uta mailing list. ietf-uta mailing list.
2. Conventions and Terminology Used in This Document 2. Conventions and Terminology Used in This Document
skipping to change at page 8, line 33 skipping to change at page 8, line 29
message submission protocol data [RFC6409] is exchanged as TLS message submission protocol data [RFC6409] is exchanged as TLS
application data for the remainder of the TCP connection. (Note: the application data for the remainder of the TCP connection. (Note: the
"submissions" service name is defined in section 10.3 of this "submissions" service name is defined in section 10.3 of this
document, and follows the usual convention that the name of a service document, and follows the usual convention that the name of a service
layered on top of Implicit TLS consists of the name of the service as layered on top of Implicit TLS consists of the name of the service as
used without TLS, with an "s" appended.) used without TLS, with an "s" appended.)
The STARTTLS mechanism on port 587 is relatively widely deployed due The STARTTLS mechanism on port 587 is relatively widely deployed due
to the situation with port 465 (discussed in Section 11.5). This to the situation with port 465 (discussed in Section 11.5). This
differs from IMAP and POP services where implicit TLS is more widely differs from IMAP and POP services where implicit TLS is more widely
deployed on servers than STARTTLS. It is desirable to migrate MUA deployed on servers than STARTTLS. It is desirable to migrate core
software to implicit TLS over time for consistency as well as the protocols used by MUA software to implicit TLS over time for
reasons discussed elsewhere in this document. However, to maximize consistency as well as the additional reasons discussed in
use of encryption for submission it is desirable to support both Appendix A. However, to maximize use of encryption for submission it
mechanisms for Message Submission over TLS for a transition period of is desirable to support both mechanisms for Message Submission over
several years. As a result, clients and servers SHOULD implement TLS for a transition period of several years. As a result, clients
both STARTTLS on port 587 and implicit TLS on port 465 for this and servers SHOULD implement both STARTTLS on port 587 and implicit
transition period. Note that there is no significant difference TLS on port 465 for this transition period. Note that there is no
between the security properties of STARTTLS on port 587 and implicit significant difference between the security properties of STARTTLS on
TLS on port 465 if the implementations are correct and both client port 587 and implicit TLS on port 465 if the implementations are
and server are configured to require successful negotiation of TLS correct and both client and server are configured to require
prior to message submission (as required in Section 9.1). successful negotiation of TLS prior to message submission (as
required in Section 9.1).
Note that the submissions port provides access to a Mail Submission Note that the submissions port provides access to a Mail Submission
Agent (MSA) as defined in [RFC6409] so requirements and Agent (MSA) as defined in [RFC6409] so requirements and
recommendations for MSAs in that document apply to the submissions recommendations for MSAs in that document apply to the submissions
port, including the requirement to implement SMTP AUTH [RFC4954]. port, including the requirement to implement SMTP AUTH [RFC4954].
See Section 9.1.1 for additional information on client certificate See Section 9.1.1 for additional information on client certificate
authentication. See Section 11.5 for port registration information. authentication. See Section 11.5 for port registration information.
4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP
skipping to change at page 22, line 27 skipping to change at page 22, line 27
Mail Service Providers MUST use server implementations that conform Mail Service Providers MUST use server implementations that conform
to this specification. to this specification.
10.2. MSPs MUST provide Submission Servers 10.2. MSPs MUST provide Submission Servers
This document updates the advice in [RFC5068] by making Implicit TLS This document updates the advice in [RFC5068] by making Implicit TLS
on port 465 the preferred submission port. on port 465 the preferred submission port.
Mail Service Providers that accept mail submissions from end-users Mail Service Providers that accept mail submissions from end-users
using the Internet Protocol MUST provide one or more SMTP Submission using the Internet Protocol MUST provide one or more SMTP Submission
servers for this purpose, separate from the SMTP servers used to services, separate from the SMTP MTA services used to process
process incoming mail. Those submission servers MUST be configured incoming mail. Those submission services MUST be configured to
to support Implicit TLS on port 465 and SHOULD support STARTTLS if support Implicit TLS on port 465 and SHOULD support STARTTLS if port
port 587 is used. 587 is used.
MSPs MAY also support submission of messages via one or more MSPs MAY also support submission of messages via one or more
designated SMTP servers to facilitate compatibility with legacy MUAs. designated SMTP servers to facilitate compatibility with legacy MUAs.
Discussion: SMTP servers used to accept incoming mail or to relay Discussion: SMTP servers used to accept incoming mail or to relay
mail are expected to accept mail in cleartext. This is incompatible mail are expected to accept mail in cleartext. This is incompatible
with the purpose of this memo which is to encourage encryption of with the purpose of this memo which is to encourage encryption of
traffic between mail servers. There is no such requirement for mail traffic between mail servers. There is no such requirement for mail
submission servers to accept mail in cleartext or without submission servers to accept mail in cleartext or without
authentication. For other reasons, use of separate SMTP submission authentication. For other reasons, use of separate SMTP submission
skipping to change at page 30, line 47 skipping to change at page 30, line 47
mail service providers can more effectively inform end-users running mail service providers can more effectively inform end-users running
old clients that they need to upgrade to protect their security, or 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 know which clients to use in a test deployment prior to upgrading a
server to have higher security requirements. server to have higher security requirements.
13. References 13. References
13.1. Normative References 13.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, May 1996. STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<http://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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998. Mechanism", RFC 2449, DOI 10.17487/RFC2449, November 1998,
<http://www.rfc-editor.org/info/rfc2449>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971,
October 2000. DOI 10.17487/RFC2971, October 2000,
<http://www.rfc-editor.org/info/rfc2971>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <http://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, March 2003. 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, for Delivery Status Notifications", RFC 3464,
January 2003. DOI 10.17487/RFC3464, January 2003,
<http://www.rfc-editor.org/info/rfc3464>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol
(POP3) Simple Authentication and Security Layer (SASL) (POP3) Simple Authentication and Security Layer (SASL)
Authentication Mechanism", RFC 5034, July 2007. Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034,
July 2007, <http://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,
November 2007. DOI 10.17487/RFC5068, November 2007,
<http://www.rfc-editor.org/info/rfc5068>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008,
<http://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, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248, June 2008. Mail System Status Codes", BCP 138, RFC 5248,
DOI 10.17487/RFC5248, June 2008,
<http://www.rfc-editor.org/info/rfc5248>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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, May 2008. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[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, March 2011. Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, March 2011. Submission/Access Services", RFC 6186, DOI 10.17487/
RFC6186, March 2011,
<http://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, November 2011. STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<http://www.rfc-editor.org/info/rfc6409>.
[I-D.ietf-uta-email-tls-certs] [I-D.ietf-uta-email-tls-certs]
Melnikov, A., "Updated TLS Server Identity Check Procedure Melnikov, A., "Updated TLS Server Identity Check Procedure
for Email Related Protocols", for Email Related Protocols",
draft-ietf-uta-email-tls-certs-03 (work in progress), draft-ietf-uta-email-tls-certs-03 (work in progress),
June 2015. June 2015.
[I-D.ietf-dane-smtp-with-dane]
Dukhovni, V. and W. Hardaker, "SMTP security via
opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-02
(work in progress), October 2013.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>.
13.2. Informative References 13.2. Informative References
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999. RFC 2595, DOI 10.17487/RFC2595, June 1999,
<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, October 2000. Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
<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, July 2004. Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004,
<http://www.rfc-editor.org/info/rfc3848>.
[RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887,
September 2004. DOI 10.17487/RFC3887, September 2004,
<http://www.rfc-editor.org/info/rfc3887>.
[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, April 2006. (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/
RFC4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Security Layer (SASL)", RFC 4422, June 2006. Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<http://www.rfc-editor.org/info/rfc4422>.
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
for Authentication", RFC 4954, July 2007. Extension for Authentication", RFC 4954, DOI 10.17487/
RFC4954, July 2007,
<http://www.rfc-editor.org/info/rfc4954>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010,
<http://www.rfc-editor.org/info/rfc5802>.
[RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC 5804, July 2010. Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804,
July 2010, <http://www.rfc-editor.org/info/rfc5804>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extension Definitions", RFC 6066, January 2011. Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[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, August 2011. RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://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, August 2012. Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, DOI 10.17487/
RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>.
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 The first version of this was written independently from
draft-moore-email-tls-00.txt; subsequent versions merge ideas from draft-moore-email-tls-00.txt; subsequent versions merge ideas from
both drafts. 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
skipping to change at page 35, line 15 skipping to change at page 36, line 18
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-02:
o Make reference to design considerations explicit rather than
"elsewhere in this document".
o Change provider requirement so SMTP submission services are
separate from SMTP MTA services as opposed to the previous
phrasing that required the servers be separate (which is too
restrictive).
o Update DANE SMTP reference
Changes since draft-ietf-uta-email-deep-01: Changes since draft-ietf-uta-email-deep-01:
o Change text in tls11 and tls12 registrations to clarify o Change text in tls11 and tls12 registrations to clarify
certificate rules, including additional PKIX and DANE references. certificate rules, including additional PKIX and DANE references.
o Change from tls10 to tls11 (including reference) as the minimum. o Change from tls10 to tls11 (including reference) as the minimum.
o Fix typo in example 5. o Fix typo in example 5.
o Remove open issues section; enough time has passed so not worth o Remove open issues section; enough time has passed so not worth
 End of changes. 45 change blocks. 
74 lines changed or deleted 135 lines changed or added

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