draft-ietf-uta-email-tls-certs-04.txt   draft-ietf-uta-email-tls-certs-05.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Updates: 2595, 3207, 3501, 5804 (if August 6, 2015 Updates: 2595, 3207, 3501, 5804 (if September 20, 2015
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: February 7, 2016 Expires: March 23, 2016
Updated TLS Server Identity Check Procedure for Email Related Protocols Updated TLS Server Identity Check Procedure for Email Related Protocols
draft-ietf-uta-email-tls-certs-04 draft-ietf-uta-email-tls-certs-05
Abstract Abstract
This document describes TLS server identity verification procedure This document describes TLS server identity verification procedure
for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces
Section 2.4 of RFC 2595. Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates
Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804.
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 February 7, 2016. This Internet-Draft will expire on March 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Email Server Certificate Verification Rules . . . . . . . . . 3 3. Email Server Certificate Verification Rules . . . . . . . . . 3
4. Compliance Checklist for Certification Authorities . . . . . 4 4. Compliance Checklist for Certification Authorities . . . . . 4
5. Compliance Checklist for Mail Service Providers and 5. Compliance Checklist for Mail Service Providers and
Certificate Signing Request generation tools . . . . . . . . 4 Certificate Signing Request generation tools . . . . . . . . 4
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 8 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is
described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804]
respectively. Each of the documents describes slightly different respectively. Each of the documents describes slightly different
rules for server certificate identity verification (or doesn't define rules for server certificate identity verification (or doesn't define
any rules at all). In reality, email client and server developers any rules at all). In reality, email client and server developers
implement many of these protocols at the same time, so it would be implement many of these protocols at the same time, so it would be
good to define modern and consistent rules for verifying email server good to define modern and consistent rules for verifying email server
skipping to change at page 3, line 5 skipping to change at page 3, line 11
protocols. This should make it easier for Certification Authorities protocols. This should make it easier for Certification Authorities
and ISPs to deploy TLS for email use, and would enable email client and ISPs to deploy TLS for email use, and would enable email client
developers to write more secure code. developers to write more secure code.
2. Conventions Used in This Document 2. Conventions 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].
The following terms or concepts are used through the document:
reference identifier: (as defined in [RFC6125]) One of the domain
names associated by the email (i.e., an SMTP, IMAP, POP3 or
ManageSieve) client with the destination email server and
optionally an application service type for performing name checks
on the server certificate. When name checks are applicable, at
least one of the reference identifiers MUST match an [RFC6125]
DNS-ID or SRV-ID (or if none are present the [RFC6125] CN-ID) of
the server certificate.
3. Email Server Certificate Verification Rules 3. Email Server Certificate Verification Rules
During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3
or ManageSieve client) MUST check its understanding of the server or ManageSieve client) MUST check its understanding of the server
hostname against the server's identity as presented in the server hostname against the server's identity as presented in the server
Certificate message, in order to prevent man-in-the-middle attacks. Certificate message, in order to prevent man-in-the-middle attacks.
Matching is performed according to the rules specified in Section 6 Matching is performed according to the rules specified in Section 6
of [RFC6125], including "certificate pinning" and the procedure on of [RFC6125], including "certificate pinning" and the procedure on
failure to match. The following inputs are used by the verification failure to match. The following inputs are used by the verification
procedure used in [RFC6125]: procedure used in [RFC6125]:
1. For DNS-ID and CN-ID identifier types the client MUST use the 1. For DNS-ID and CN-ID identifier types the client MUST use one or
server hostname it used to open the connection as at least one of more of the following as "reference identifiers": (a) the right
the values to compare against (*) in the server certificate. The hand side of the email address, (b) the hostname it used to open
client MUST NOT use any form of the server hostname derived from the connection (without CNAME canonicalization). The client MAY
an insecure remote source (e.g., insecure DNS lookup). CNAME also use (c) a value securely derived from (a) or (b), such as
canonicalization is not done. using "secure" DNSSEC validated lookup.
2. When using email service discovery procedure specified in 2. When using email service discovery procedure specified in
[RFC6186] the client MUST also use the right hand side of the [RFC6186] the client MUST also use the right hand side of the
email address as another "reference identifier" to compare email address as another "reference identifier" to compare
against in the server certificate. against SRV-ID identifier in the server certificate.
(*) - "reference identifier" (see the definition in [RFC6125]).
The rules and guidelines defined in [RFC6125] apply to an email The rules and guidelines defined in [RFC6125] apply to an email
server certificates, with the following supplemental rules: server certificates, with the following supplemental rules:
1. Support for the DNS-ID identifier type (subjectAltName of dNSName 1. Support for the DNS-ID identifier type (subjectAltName of dNSName
type [RFC5280]) is REQUIRED in Email client software type [RFC5280]) is REQUIRED in Email client software
implementations. implementations.
2. Support for the SRV-ID identifier type (subjectAltName of SRVName 2. Support for the SRV-ID identifier type (subjectAltName of SRVName
type [RFC4985]) is REQUIRED for email client software type [RFC4985]) is REQUIRED for email client software
skipping to change at page 6, line 37 skipping to change at page 7, line 5
9. References 9. References
9.1. Normative References 9.1. Normative References
[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>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[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>.
[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, <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, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
 End of changes. 11 change blocks. 
22 lines changed or deleted 28 lines changed or added

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