idnits 2.17.1 draft-ietf-uta-email-tls-certs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2595, but the abstract doesn't seem to directly say this. It does mention RFC2595 though, so this could be OK. -- The draft header indicates that this document updates RFC3207, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2595, updated by this document, for RFC5378 checks: 1997-08-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 11, 2014) is 3512 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5321' is defined on line 178, but no explicit reference was found in the text == Unused Reference: 'RFC2595' is defined on line 213, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Updates: 2595, 3207 (if approved) September 11, 2014 5 Intended status: Standards Track 6 Expires: March 15, 2015 8 Updated TLS Server Identity Check Procedure for Email Related Protocols 9 draft-ietf-uta-email-tls-certs-00 11 Abstract 13 This document describes TLS server identity verification procedure 14 for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces 15 Section 2.4 of RFC 2595. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 15, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 53 3. Email Server Certificate Verification Rules . . . . . . . . . 2 54 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 7.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 This document describes the updated TLS server identity verification 65 procedure for SMTP Submission [RFC4409] [RFC3207], IMAP [RFC3501], 66 POP [RFC1939] and ManageSieve [RFC5804] clients. It replaces 67 Section 2.4 of RFC 2595. 69 Note that this document doesn't apply to use of TLS in MTA-to-MTA 70 SMTP. 72 The main goal of the document is to provide consistent TLS server 73 identity verification procedure across multiple email related 74 protocols. This should make it easier for Certificate Authorities 75 and ISPs to deploy TLS for email use, and would enable email client 76 developers to write more secure code. 78 2. Conventions Used in This Document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 3. Email Server Certificate Verification Rules 86 During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 87 or ManageSieve client) MUST check its understanding of the server 88 hostname against the server's identity as presented in the server 89 Certificate message, in order to prevent man-in-the-middle attacks. 90 Matching is performed according to the rules specified in Section 6 91 of [RFC6125], including "certificate pinning" and the procedure on 92 failure to match. The following inputs are used by the verification 93 procedure used in [RFC6125]: 95 1. The client MUST use the server hostname it used to open the 96 connection as the value to compare against the server name as 97 expressed in the server certificate (the reference identity). 98 The client MUST NOT use any form of the server hostname derived 99 from an insecure remote source (e.g., insecure DNS lookup). 100 CNAME canonicalization is not done. 102 The rules and guidelines defined in [RFC6125] apply to an email 103 server certificates, with the following supplemental rules: 105 1. Support for the DNS-ID identifier type (subjectAltName of dNSName 106 type [RFC5280]) is REQUIRED in Email client software 107 implementations. Certification authorities that issue Email- 108 specific certificates MUST support the DNS-ID identifier type. 109 Service providers SHOULD include the DNS-ID identifier type in 110 Certificate Signing Requests. 112 2. Support for the SRV-ID identifier type (subjectAltName of SRVName 113 type [RFC4985]) is REQUIRED for email client software 114 implementations. Certification authorities that issue email- 115 specific certificates MUST support the SRV-ID identifier type. 116 Service providers SHOULD include the SRV-ID identifier type in 117 Certificate Signing Requests. List of SRV-ID types for email 118 services is specified in [RFC6186]. For ManageSieve the value 119 "sieve" is used. 121 3. URI-ID identifier type (subjectAltName of 122 uniformResourceIdentifier type [RFC5280]) MUST NOT be used by 123 clients for server verification. 125 4. For backward compatibility with deployed software CN-ID 126 identifier type (CN attribute from the subject name, see 127 [RFC6125]) MAY be used for server identity verification. 129 5. Email protocols allow use of certain wilcards in identifiers 130 presented by email servers. The "*" wildcard character MAY be 131 used as the left-most name component of DNS-ID or CN-ID in the 132 certificate. For example, a DNS-ID of *.example.com would match 133 a.example.com, foo.example.com, etc. but would not match 134 example.com. Note that the wildcard character MUST NOT be used 135 as a fragment of the left-most name component (e.g., 136 *oo.example.com, f*o.example.com, or foo*.example.com). 138 4. Examples 140 Consider an IMAP-accessible email server which supports both IMAP and 141 IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email 142 addresses of the form "user@example.net" and discoverable via DNS SRV 143 lookups on the application service name of "example.net". A 144 certificate for this service needs to include SRV-IDs of 145 "_imap.example.net" and "_imaps.example.net" (see [RFC6186]) along 146 with DNS-IDs of "example.net" and "mail.example.net". It might also 147 include CN-IDs of "example.net" and "mail.example.net" for backward 148 compatibility with deployed infrastructure. 150 Consider an SMTP Submission server at the host "submit.example.net" 151 servicing email addresses of the form "user@example.net" and 152 discoverable via DNS SRV lookups on the application service name of 153 "example.net". A certificate for this service needs to include SRV- 154 IDs of "_submission.example.net" (see [RFC6186]) along with DNS-IDs 155 of "example.net" and "submit.example.net". It might also include CN- 156 IDs of "example.net" and "submit.example.net" for backward 157 compatibility with deployed infrastructure. 159 5. IANA Considerations 161 This document doesn't require any action from IANA. 163 6. Security Considerations 165 The goal of this document is to improve interoperability and thus 166 security of email clients wishing to access email servers over TLS 167 protected email protocols, by specifying a consistent set of rules 168 that email service providers, email client writers and certificate 169 authorities can use when creating server certificates. 171 7. References 173 7.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997. 178 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 179 October 2008. 181 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 182 RFC 4409, April 2006. 184 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 185 Transport Layer Security", RFC 3207, February 2002. 187 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 188 4rev1", RFC 3501, March 2003. 190 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 191 STD 53, RFC 1939, May 1996. 193 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 194 Managing Sieve Scripts", RFC 5804, July 2010. 196 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 197 Verification of Domain-Based Application Service Identity 198 within Internet Public Key Infrastructure Using X.509 199 (PKIX) Certificates in the Context of Transport Layer 200 Security (TLS)", RFC 6125, March 2011. 202 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 203 Housley, R., and W. Polk, "Internet X.509 Public Key 204 Infrastructure Certificate and Certificate Revocation List 205 (CRL) Profile", RFC 5280, May 2008. 207 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 208 Subject Alternative Name for Expression of Service Name", 209 RFC 4985, August 2007. 211 7.2. Informative References 213 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 214 2595, June 1999. 216 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 217 Submission/Access Services", RFC 6186, March 2011. 219 Appendix A. Acknowledgements 221 Thank you to Chris Newman for comments on this document. 223 The editor of this document copied lots of text from RFC 2595 and RFC 224 6125, so the hard work of editors of these document is appreciated. 226 Author's Address 228 Alexey Melnikov 229 Isode Ltd 230 14 Castle Mews 231 Hampton, Middlesex TW12 2NP 232 UK 234 EMail: Alexey.Melnikov@isode.com