draft-ietf-uta-email-deep-03.txt   draft-ietf-uta-email-deep-04.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 11, 2016 Intended status: Standards Track March 17, 2016
Expires: September 12, 2016 Expires: September 18, 2016
Deployable Enhanced Email Privacy (DEEP) Deployable Enhanced Email Privacy (DEEP)
draft-ietf-uta-email-deep-03.txt draft-ietf-uta-email-deep-04.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 12, 2016. This Internet-Draft will expire on September 18, 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 19, line 27 skipping to change at page 19, line 27
o All implementations MUST implement the recommended cipher suites o All implementations MUST implement the recommended 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 All implementations MUST be configurable to require TLS before o All implementations MUST be configurable to require TLS before
performing any operation other than capability discovery and performing any operation other than capability discovery and
STARTTLS. STARTTLS.
o The IMAP specification [RFC3501] is hereby modified to revoke the o The IMAP specification [RFC3501] is hereby modified to revoke the
second paragraph of section 11.1 and replace it with the text from second paragraph of section 11.1 and replace it with the text from
the first three bullet items in this list. the first three bullet items in this list. See Appendix B of
[I-D.ietf-uta-email-tls-certs] to see additional modifications to
IMAP certificate validation rules.
o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is
modified to revoke section 2.1 and replace it with the text from modified to revoke section 2.1 and replace it with the text from
the first three bullet items in this list. the first three bullet items in this list. See Appendix B of
[I-D.ietf-uta-email-tls-certs] to see additional modifications to
RFC 2595 certificate validation rules.
o The standard for Message Submission [RFC6409] is updated to add o The standard for Message Submission [RFC6409] is updated to add
the first three bullet items above to section 4.3 as well as to the first three bullet items above to section 4.3 as well as to
require implementation of the TLS server identity check as require implementation of the TLS server identity check as
described in [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. described in [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280].
9.1.1. Client Certificate Authentication 9.1.1. Client Certificate Authentication
MUAs and mail servers MAY implement client certificate authentication MUAs and mail servers MAY implement client certificate authentication
on the implicit TLS port. Servers MUST NOT request a client on the implicit TLS port. Servers MUST NOT request a client
skipping to change at page 22, line 45 skipping to change at page 22, line 49
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
servers has been best practice for many years. servers has been best practice for many years.
10.3. TLS Server Certificate Requirements 10.3. TLS Server Certificate Requirements
MSPs MUST maintain valid server certificates for all servers. Those MSPs MUST maintain valid server certificates for all servers. See
server certificates SHOULD present DNS-IDs and SRV-IDs conforming to [I-D.ietf-uta-email-tls-certs] for the recommendations and
[RFC6125] and which will be recognized by MUAs meeting the requirements necessary to achieve this.
requirements of that specification. In addition, those server
certificates MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for
compatibility with existing MUAs.
If a protocol server provides service for more than one mail domain, If a protocol server provides service for more than one mail domain,
it MAY use a separate IP address for each domain and/or a server it MAY use a separate IP address for each domain and/or a server
certificate that advertises multiple domains. This will generally be certificate that advertises multiple domains. This will generally be
necessary unless and until it is acceptable to impose the constraint necessary unless and until it is acceptable to impose the constraint
that the server and all clients support the Server Name Indication that the server and all clients support the Server Name Indication
extension to TLS [RFC6066]. extension to TLS [RFC6066]. For more discussion of this problem, see
section 5.1 of [I-D.ietf-uta-email-tls-certs].
10.4. Recommended DNS records for mail protocol servers 10.4. Recommended DNS records for mail protocol servers
This section discusses not only the DNS records that are recommended, This section discusses not only the DNS records that are recommended,
but also implications of DNS records for server configuration and TLS but also implications of DNS records for server configuration and TLS
server certificates. server certificates.
10.4.1. MX records 10.4.1. MX records
It is recommended that MSPs advertise MX records for handling of It is recommended that MSPs advertise MX records for handling of
skipping to change at page 32, line 35 skipping to change at page 32, line 35
<http://www.rfc-editor.org/info/rfc5280>. <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,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>. <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,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
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, DOI 10.17487/ Submission/Access Services", RFC 6186, DOI 10.17487/
RFC6186, March 2011, RFC6186, March 2011,
<http://www.rfc-editor.org/info/rfc6186>. <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, DOI 10.17487/RFC6409, November 2011, STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<http://www.rfc-editor.org/info/rfc6409>. <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-09 (work in progress),
June 2015. December 2015.
[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, (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
May 2015, <http://www.rfc-editor.org/info/rfc7525>. May 2015, <http://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,
skipping to change at page 34, line 25 skipping to change at page 34, line 18
[RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804,
July 2010, <http://www.rfc-editor.org/info/rfc5804>. July 2010, <http://www.rfc-editor.org/info/rfc5804>.
[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>. <http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
March 2011, <http://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>. <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, DOI 10.17487/RFC6698, Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
skipping to change at page 36, line 18 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-03:
o Add more references to ietf-uta-email-tls-certs in implementation
requirements section.
o Replace primary reference to RFC 6125 with ietf-uta-email-tls-
certs, so move RFC 6125 to informative list for this
specification.
Changes since draft-ietf-uta-email-deep-02: Changes since draft-ietf-uta-email-deep-02:
o Make reference to design considerations explicit rather than o Make reference to design considerations explicit rather than
"elsewhere in this document". "elsewhere in this document".
o Change provider requirement so SMTP submission services are o Change provider requirement so SMTP submission services are
separate from SMTP MTA services as opposed to the previous separate from SMTP MTA services as opposed to the previous
phrasing that required the servers be separate (which is too phrasing that required the servers be separate (which is too
restrictive). restrictive).
 End of changes. 11 change blocks. 
22 lines changed or deleted 33 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/