draft-ietf-uta-email-tls-certs-06.txt | draft-ietf-uta-email-tls-certs-07.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 December 4, 2015 | Updates: 2595, 3207, 3501, 5804 (if December 9, 2015 | |||
approved) | approved) | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: June 6, 2016 | Expires: June 11, 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-06 | draft-ietf-uta-email-tls-certs-07 | |||
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, updates Section 4.1 of RFC 3207, updates | 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. | Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
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 June 6, 2016. | This Internet-Draft will expire on June 11, 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 | |||
skipping to change at page 2, line 13 | skipping to change at page 2, line 13 | |||
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 . . . . . . . . . . . . . . 3 | 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 . . . . . 5 | 4. Compliance Checklist for Certification Authorities . . . . . 5 | |||
4.1. Notes on handling of SRV-ID by Certificate Authorities . 5 | 4.1. Notes on handling of SRV-ID by Certification Authorities 5 | |||
5. Compliance Checklist for Mail Service Providers and | 5. Compliance Checklist for Mail Service Providers and | |||
Certificate Signing Request generation tools . . . . . . . . 5 | Certificate Signing Request generation tools . . . . . . . . 6 | |||
5.1. Notes on hosted domains . . . . . . . . . . . . . . . . . 6 | 5.1. Notes on hosting multiple domains . . . . . . . . . . . . 6 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 8 | 9.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 | |||
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 10 | Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 11 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
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 4, line 12 | skipping to change at page 4, line 12 | |||
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 one or | 1. For DNS-ID and CN-ID identifier types the client MUST use one or | |||
more of the following as "reference identifiers": (a) the domain | more of the following as "reference identifiers": (a) the domain | |||
portion of the user's email address, (b) the hostname it used to | portion of the user's email address, (b) the hostname it used to | |||
open the connection (without CNAME canonicalization). The client | open the connection (without CNAME canonicalization). The client | |||
MAY also use (c) a value securely derived from (a) or (b), such | MAY also use (c) a value securely derived from (a) or (b), such | |||
as using "secure" DNSSEC validated lookup. | as using "secure" DNSSEC [RFC4033][RFC4034][RFC4035] 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 domain portion of the | [RFC6186] the client MUST also use the domain portion of the | |||
user's email address as another "reference identifier" to compare | user's email address as another "reference identifier" to compare | |||
against SRV-ID identifier in the server certificate. | against SRV-ID identifier in the server certificate. | |||
The rules and guidelines defined in [RFC6125] apply to an email | The rules and guidelines defined in [RFC6125] apply to an email | |||
server certificate, with the following supplemental rules: | server certificate, 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 | |||
skipping to change at page 5, line 22 | skipping to change at page 5, line 22 | |||
each type of email service. See Section 4.1 for more discussion | each type of email service. See Section 4.1 for more discussion | |||
on what this means for Certification Authorities. | on what this means for Certification Authorities. | |||
3. For backward compatibility with deployed client base, CA MUST | 3. For backward compatibility with deployed client base, CA MUST | |||
support issuance of server certificates with CN-ID identifier | support issuance of server certificates with CN-ID identifier | |||
type (CN attribute from the subject name, see [RFC6125]). | type (CN attribute from the subject name, see [RFC6125]). | |||
4. CA MAY allow "*" (wildcard) as the left-most name component of | 4. CA MAY allow "*" (wildcard) as the left-most name component of | |||
DNS-ID or CN-ID in server certificates it issues. | DNS-ID or CN-ID in server certificates it issues. | |||
4.1. Notes on handling of SRV-ID by Certificate Authorities | 4.1. Notes on handling of SRV-ID by Certification Authorities | |||
TBD. List some possible recommendations and limitations of different | [RFC6186] provides an easy way for organizations to autoconfigure | |||
approaches. | email clients. It also allows for delegation of email services to an | |||
email hosting provider. When connecting to such delegated hosting | ||||
service an email client that attempts to verify TLS server identity | ||||
needs to know that if it connects to imap.hosting.example.net that | ||||
such server is authorized to provide email access for an email such | ||||
as alice@example.org. In absence of SRV-IDs, users of compliant | ||||
email clients would be forced to manual confirm exception, because | ||||
TLS server certificate verification procedures specified in this | ||||
document would result in failure to match TLS server certificate | ||||
against the expected domains. One way to provide such authorization | ||||
is for the TLS certificate for imap.hosting.example.net to include | ||||
SRV-ID(s) (or DNS-ID) for example.org domain. (Another way is for | ||||
SRV lookups to be protected by DNSSEC, but this solution depends | ||||
reliance of DNSSEC and thus is not discussed in this document. A | ||||
future update to this document might rectify this.) | ||||
The ability of issuing certificates that contain SRV-ID implies the | ||||
ability to verify that entities requesting them are authorized to run | ||||
email service for these SRV-IDs. In particular, certification | ||||
authorities that can't verify such authorization MUST NOT include | ||||
email SRV-IDs in certificates they issue. This document doesn't | ||||
specify exact mechanism(s) that can be used to achieve this. | ||||
However, a few special case recommendations are listed below. | ||||
A certification authority willing to sign a certificate containing a | ||||
particular DNS-ID SHOULD also support signing a certificate | ||||
containing one or more of email SRV-IDs for the same domain, because | ||||
the SRV-ID effectively provides more restricted access to an email | ||||
service for the domain (as opposed to unrestricted use of any | ||||
services for the same domain, as specified by DNS-ID). | ||||
A certification authority which also provides DNS service for a | ||||
domain can use DNS information to validate SRV-IDs for the domain. | ||||
A certification authority MAY treat a certificate for a subdomain of | ||||
example.com (e.g. imap.sub1.example.com or imap.example.com) that | ||||
contains one or more SRV-ID for example.com as validated. | ||||
5. Compliance Checklist for Mail Service Providers and Certificate | 5. Compliance Checklist for Mail Service Providers and Certificate | |||
Signing Request generation tools | Signing Request generation tools | |||
1. MUST include the DNS-ID identifier type in Certificate Signing | 1. MUST include the DNS-ID identifier type in Certificate Signing | |||
Requests for the host name(s) where the email server(s) are | Requests for the host name(s) where the email server(s) are | |||
running. SHOULD include the DNS-ID identifier type in | running. SHOULD include the DNS-ID identifier type in | |||
Certificate Signing Requests for the domain portion of served | Certificate Signing Requests for the domain portion of served | |||
email addresses. | email addresses. | |||
skipping to change at page 6, line 5 | skipping to change at page 6, line 40 | |||
backward compatibility with deployed email clients. (Note, a | backward compatibility with deployed email clients. (Note, a | |||
certificate can only include a single CN-ID, so if a mail service | certificate can only include a single CN-ID, so if a mail service | |||
is running on multiple hosts, either each host has to use | is running on multiple hosts, either each host has to use | |||
different certificate with its own CN-ID, a single certificate | different certificate with its own CN-ID, a single certificate | |||
with multiple DNS-IDs, or a single certificate with wildcard in | with multiple DNS-IDs, or a single certificate with wildcard in | |||
CN-ID can be used). | CN-ID can be used). | |||
4. MAY include "*" (wildcard) as the left-most name component of | 4. MAY include "*" (wildcard) as the left-most name component of | |||
DNS-ID or CN-ID in Certificate Signing Requests. | DNS-ID or CN-ID in Certificate Signing Requests. | |||
5.1. Notes on hosted domains | 5.1. Notes on hosting multiple domains | |||
TBD. Compare one certificate that contains all hosted domains versa | A server that hosts multiple domains needs to do one of the following | |||
use of SNI or separate IPs for each hosted domain with its own | (or some combination thereof): | |||
certificate. | ||||
1. Use a single TLS certificate that includes a complete list of all | ||||
the domains it is serving. | ||||
2. Serve each domain on its own IP/port, using separate TLS | ||||
certificates on each IP/port. | ||||
3. Use Server Name Indication (SNI) TLS extension [RFC6066] to | ||||
select the right certificate to return during TLS negotiation. | ||||
Each domain has its own TLS certificate in this case. | ||||
Each of these deployment choices have their scaling disadvantages | ||||
when the list of domains changes. A single certificate (the first | ||||
choice) requires that when a domain is added, then a new Certificate | ||||
Signing Request that includes a complete list of all the domains | ||||
needs to be issued and passed to a CA in order to generate a new | ||||
certificate. Separate IP/port can avoid regenerating the | ||||
certificate, but requires more transport layer resources. Use of TLS | ||||
SNI requires each email client to support it. | ||||
Several Mail Service Providers host hundreds and even thousands of | ||||
domain. This document, as well as its predecessors RFC 2595, RFC | ||||
3207, RFC 3501 and RFC 5804 don't address scaling issues caused by | ||||
use of TLS in multi-tenanted environments. Further work is needed to | ||||
address this issue, possibly using DNSSEC or something like POSH | ||||
[RFC7711]. | ||||
6. Examples | 6. Examples | |||
Consider an IMAP-accessible email server which supports both IMAP and | Consider an IMAP-accessible email server which supports both IMAP and | |||
IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email | IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email | |||
addresses of the form "user@example.net". A certificate for this | addresses of the form "user@example.net". A certificate for this | |||
service needs to include DNS-IDs of "example.net" (because it is the | service needs to include DNS-IDs of "example.net" (because it is the | |||
domain portion of emails) and "mail.example.net" (this is what a user | domain portion of emails) and "mail.example.net" (this is what a user | |||
of this server enters manually, if not using [RFC6186]). It might | of this server enters manually, if not using [RFC6186]). It might | |||
also include CN-ID of "mail.example.net" for backward compatibility | also include CN-ID of "mail.example.net" for backward compatibility | |||
skipping to change at page 9, line 10 | skipping to change at page 10, line 20 | |||
[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>. | <http://www.rfc-editor.org/info/rfc2595>. | |||
[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, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<http://www.rfc-editor.org/info/rfc3986>. | <http://www.rfc-editor.org/info/rfc3986>. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "DNS Security Introduction and Requirements", | ||||
RFC 4033, DOI 10.17487/RFC4033, March 2005, | ||||
<http://www.rfc-editor.org/info/rfc4033>. | ||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "Resource Records for the DNS Security Extensions", | ||||
RFC 4034, DOI 10.17487/RFC4034, March 2005, | ||||
<http://www.rfc-editor.org/info/rfc4034>. | ||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "Protocol Modifications for the DNS Security | ||||
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | ||||
<http://www.rfc-editor.org/info/rfc4035>. | ||||
[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>. | <http://www.rfc-editor.org/info/rfc5234>. | |||
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | ||||
Extensions: Extension Definitions", RFC 6066, | ||||
DOI 10.17487/RFC6066, January 2011, | ||||
<http://www.rfc-editor.org/info/rfc6066>. | ||||
[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, <http://www.rfc-editor.org/info/rfc6698>. | |||
[RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP | ||||
(POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, | ||||
<http://www.rfc-editor.org/info/rfc7711>. | ||||
Appendix A. Acknowledgements | Appendix A. Acknowledgements | |||
Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ Housley | Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ | |||
and Alessandro Vesely for comments on this document. | Housley, Alessandro Vesely, Harald Alvestrand and John Levine for | |||
comments on this document. | ||||
The editor of this document copied lots of text from RFC 2595 and RFC | The editor of this document copied lots of text from RFC 2595 and RFC | |||
6125, so the hard work of editors of these document is appreciated. | 6125, so the hard work of editors of these document is appreciated. | |||
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 | Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 | |||
[[Note to RFC Editor: Please delete this section before publication]] | [[Note to RFC Editor: Please delete this section before publication]] | |||
Added another example, clarified that subjectAltName and DNS SRV are | Added another example, clarified that subjectAltName and DNS SRV are | |||
using slightly different syntax. | using slightly different syntax. | |||
End of changes. 15 change blocks. | ||||
26 lines changed or deleted | 113 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/ |