idnits 2.17.1 draft-ietf-uta-email-tls-certs-06.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 RFC5804, but the abstract doesn't seem to directly say this. It does mention RFC5804 though, so this could be OK. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to directly say this. It does mention RFC3501 though, so this could be OK. -- The draft header indicates that this document updates RFC3207, but the abstract doesn't seem to directly say this. It does mention RFC3207 though, so this could be OK. 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 (December 4, 2015) is 3059 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) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 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, 3501, 5804 (if December 4, 2015 5 approved) 6 Intended status: Standards Track 7 Expires: June 6, 2016 9 Updated TLS Server Identity Check Procedure for Email Related Protocols 10 draft-ietf-uta-email-tls-certs-06 12 Abstract 14 This document describes TLS server identity verification procedure 15 for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces 16 Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates 17 Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 6, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Email Server Certificate Verification Rules . . . . . . . . . 3 56 4. Compliance Checklist for Certification Authorities . . . . . 5 57 4.1. Notes on handling of SRV-ID by Certificate Authorities . 5 58 5. Compliance Checklist for Mail Service Providers and 59 Certificate Signing Request generation tools . . . . . . . . 5 60 5.1. Notes on hosted domains . . . . . . . . . . . . . . . . . 6 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 9.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 68 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is 74 described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] 75 respectively. Each of the documents describes slightly different 76 rules for server certificate identity verification (or doesn't define 77 any rules at all). In reality, email client and server developers 78 implement many of these protocols at the same time, so it would be 79 good to define modern and consistent rules for verifying email server 80 identities using TLS. 82 This document describes the updated TLS server identity verification 83 procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], 84 POP [RFC1939] and ManageSieve [RFC5804] clients. It replaces 85 Section 2.4 of RFC 2595. 87 Note that this document doesn't apply to use of TLS in MTA-to-MTA 88 SMTP. 90 This document provides a consistent TLS server identity verification 91 procedure across multiple email related protocols. This should make 92 it easier for Certification Authorities and ISPs to deploy TLS for 93 email use, and would enable email client developers to write more 94 secure code. 96 2. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 The following terms or concepts are used through the document: 104 reference identifier: (as defined in [RFC6125]) One of the domain 105 names associated by the email (i.e., an SMTP, IMAP, POP3 or 106 ManageSieve) client with the target email server and optionally an 107 application service type for performing name checks on the server 108 certificate. When name checks are applicable, at least one of the 109 reference identifiers MUST match an [RFC6125] DNS-ID or SRV-ID (or 110 if none are present the [RFC6125] CN-ID) of the server 111 certificate. 113 CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] 114 for details). For convenience, their short definitions from 115 [RFC6125] are listed below: 117 CN-ID = a Relative Distinguished Name (RDN) in the certificate 118 subject field that contains one and only one attribute-type-and- 119 value pair of type Common Name (CN), where the value matches the 120 overall form of a domain name (informally, dot- separated letter- 121 digit-hyphen labels). 123 DNS-ID = a subjectAltName entry of type dNSName 125 SRV-ID = a subjectAltName entry of type otherName whose name form 126 is SRVName 128 URI-ID = a subjectAltName entry of type uniformResourceIdentifier 129 whose value includes both (i) a "scheme" and (ii) a "host" 130 component (or its equivalent) that matches the "reg-name" rule 131 (where the quoted terms represent the associated [RFC5234] 132 productions from [RFC3986]). 134 3. Email Server Certificate Verification Rules 136 During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 137 or ManageSieve client) MUST check its understanding of the server 138 hostname against the server's identity as presented in the server 139 Certificate message, in order to prevent man-in-the-middle attacks. 140 This check is only performed after the server certificate passes 141 certification path validation as described in Section 6 of [RFC5280]. 142 Matching is performed according to the rules specified in Section 6 143 of [RFC6125], including "certificate pinning" and the procedure on 144 failure to match. The following inputs are used by the verification 145 procedure used in [RFC6125]: 147 1. For DNS-ID and CN-ID identifier types the client MUST use one or 148 more of the following as "reference identifiers": (a) the domain 149 portion of the user's email address, (b) the hostname it used to 150 open the connection (without CNAME canonicalization). The client 151 MAY also use (c) a value securely derived from (a) or (b), such 152 as using "secure" DNSSEC validated lookup. 154 2. When using email service discovery procedure specified in 155 [RFC6186] the client MUST also use the domain portion of the 156 user's email address as another "reference identifier" to compare 157 against SRV-ID identifier in the server certificate. 159 The rules and guidelines defined in [RFC6125] apply to an email 160 server certificate, with the following supplemental rules: 162 1. Support for the DNS-ID identifier type (subjectAltName of dNSName 163 type [RFC5280]) is REQUIRED in Email client software 164 implementations. 166 2. Support for the SRV-ID identifier type (subjectAltName of SRVName 167 type [RFC4985]) is REQUIRED for email client software 168 implementations that support [RFC6186]. List of SRV-ID types for 169 email services is specified in [RFC6186]. For the ManageSieve 170 protocol the service name "sieve" is used. 172 3. URI-ID identifier type (subjectAltName of 173 uniformResourceIdentifier type [RFC5280]) MUST NOT be used by 174 clients for server verification, as URI-ID were not historically 175 used for email. 177 4. For backward compatibility with deployed software CN-ID 178 identifier type (CN attribute from the subject name, see 179 [RFC6125]) MAY be used for server identity verification. 181 5. Email protocols allow use of certain wilcards in identifiers 182 presented by email servers. The "*" wildcard character MAY be 183 used as the left-most name component of DNS-ID or CN-ID in the 184 certificate. For example, a DNS-ID of *.example.com would match 185 a.example.com, foo.example.com, etc. but would not match 186 example.com. Note that the wildcard character MUST NOT be used 187 as a fragment of the left-most name component (e.g., 188 *oo.example.com, f*o.example.com, or foo*.example.com). 190 4. Compliance Checklist for Certification Authorities 192 1. CA MUST support issuance of server certificates with DNS-ID 193 identifier type (subjectAltName of dNSName type [RFC5280]). 195 2. CA MUST support issuance of server certificates with SRV-ID 196 identifier type (subjectAltName of SRVName type [RFC4985]) for 197 each type of email service. See Section 4.1 for more discussion 198 on what this means for Certification Authorities. 200 3. For backward compatibility with deployed client base, CA MUST 201 support issuance of server certificates with CN-ID identifier 202 type (CN attribute from the subject name, see [RFC6125]). 204 4. CA MAY allow "*" (wildcard) as the left-most name component of 205 DNS-ID or CN-ID in server certificates it issues. 207 4.1. Notes on handling of SRV-ID by Certificate Authorities 209 TBD. List some possible recommendations and limitations of different 210 approaches. 212 5. Compliance Checklist for Mail Service Providers and Certificate 213 Signing Request generation tools 215 1. MUST include the DNS-ID identifier type in Certificate Signing 216 Requests for the host name(s) where the email server(s) are 217 running. SHOULD include the DNS-ID identifier type in 218 Certificate Signing Requests for the domain portion of served 219 email addresses. 221 2. If the email services provided are discoverable using DNS SRV as 222 specified in [RFC6186], the Mail Service Provider MUST include 223 the SRV-ID identifier type for each type of email service in 224 Certificate Signing Requests. 226 3. SHOULD include CN-ID identifier type for the host name where the 227 email server(s) is running in Certificate Signing Requests for 228 backward compatibility with deployed email clients. (Note, a 229 certificate can only include a single CN-ID, so if a mail service 230 is running on multiple hosts, either each host has to use 231 different certificate with its own CN-ID, a single certificate 232 with multiple DNS-IDs, or a single certificate with wildcard in 233 CN-ID can be used). 235 4. MAY include "*" (wildcard) as the left-most name component of 236 DNS-ID or CN-ID in Certificate Signing Requests. 238 5.1. Notes on hosted domains 240 TBD. Compare one certificate that contains all hosted domains versa 241 use of SNI or separate IPs for each hosted domain with its own 242 certificate. 244 6. Examples 246 Consider an IMAP-accessible email server which supports both IMAP and 247 IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email 248 addresses of the form "user@example.net". A certificate for this 249 service needs to include DNS-IDs of "example.net" (because it is the 250 domain portion of emails) and "mail.example.net" (this is what a user 251 of this server enters manually, if not using [RFC6186]). It might 252 also include CN-ID of "mail.example.net" for backward compatibility 253 with deployed infrastructure. 255 Consider the IMAP-accessible email server from the previous paragraph 256 which is additionally discoverable via DNS SRV lookups in domain 257 "example.net" (DNS SRV records "_imap._tcp.example.net" and 258 "_imaps._tcp.example.net"). In addition to DNS-ID/CN-ID identity 259 types specified above, a certificate for this service also needs to 260 include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the 261 IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). 262 See [RFC6186] for more details. (Note that unlike DNS SRV there is 263 no "_tcp" component in SRV-IDs). 265 Consider the IMAP-accessible email server from the first paragraph 266 which is running on a host also known as "mycompany.example.com". In 267 addition to DNS-ID identity types specified above, a certificate for 268 this service also needs to include DNS-ID of "mycompany.example.com" 269 (this is what a user of this server enters manually, if not using 270 [RFC6186]). It might also include CN-ID of "mycompany.example.com" 271 instead of the CN-ID "mail.example.net" for backward compatibility 272 with deployed infrastructure. (This is so, because a certificate can 273 only include a single CN-ID) 275 Consider an SMTP Submission server at the host "submit.example.net" 276 servicing email addresses of the form "user@example.net" and 277 discoverable via DNS SRV lookups in domain "example.net" (DNS SRV 278 records "_submission._tcp.example.net"). A certificate for this 279 service needs to include SRV-IDs of "_submission.example.net" (see 280 [RFC6186]) along with DNS-IDs of "example.net" and 281 "submit.example.net". It might also include CN-ID of 282 "submit.example.net" for backward compatibility with deployed 283 infrastructure. 285 Consider a host "mail.example.net" servicing email addresses of the 286 form "user@example.net" and discoverable via DNS SRV lookups in 287 domain "example.net", which runs SMTP Submission, IMAPS and POP3S 288 (POP3-over-TLS) and ManageSieve services. Each of the servers can 289 use their own certificate specific to their service (see examples 290 above). Alternatively they can all share a single certificate that 291 would include SRV-IDs of "_submission.example.net", 292 "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" 293 along with DNS-IDs of "example.net" and "mail.example.net". It might 294 also include CN-ID of "mail.example.net" for backward compatibility 295 with deployed infrastructure. 297 7. IANA Considerations 299 This document doesn't require any action from IANA. 301 8. Security Considerations 303 The goal of this document is to improve interoperability and thus 304 security of email clients wishing to access email servers over TLS 305 protected email protocols, by specifying a consistent set of rules 306 that email service providers, email client writers and Certification 307 Authorities can use when creating server certificates. 309 TLS Server Identity Check for Email relies on use of trustworthy DNS 310 hostnames when constructing "reference identifiers" that are checked 311 against an email server certificate. Such trustworthy names are 312 either entered manually (for example if they are advertised on a Mail 313 Service Provider's website), explicitly confirmed by the user (e.g. 314 if they are a target of a DNS SRV lookup) or derived using a secure 315 third party service (e.g. DNSSEC-protected SRV records which are 316 verified by the client or trusted local resolver). Future work in 317 this area might benefit from integration with DANE [RFC6698], but it 318 is not covered by this document. 320 9. References 322 9.1. Normative References 324 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 325 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 326 . 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 334 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 335 February 2002, . 337 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 338 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 339 . 341 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 342 Subject Alternative Name for Expression of Service Name", 343 RFC 4985, DOI 10.17487/RFC4985, August 2007, 344 . 346 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 347 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, 348 July 2010, . 350 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 351 Housley, R., and W. Polk, "Internet X.509 Public Key 352 Infrastructure Certificate and Certificate Revocation List 353 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 354 . 356 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 357 Verification of Domain-Based Application Service Identity 358 within Internet Public Key Infrastructure Using X.509 359 (PKIX) Certificates in the Context of Transport Layer 360 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 361 2011, . 363 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 364 Submission/Access Services", RFC 6186, 365 DOI 10.17487/RFC6186, March 2011, 366 . 368 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 369 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 370 . 372 9.2. Informative References 374 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 375 RFC 2595, DOI 10.17487/RFC2595, June 1999, 376 . 378 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 379 Resource Identifier (URI): Generic Syntax", STD 66, 380 RFC 3986, DOI 10.17487/RFC3986, January 2005, 381 . 383 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 384 Specifications: ABNF", STD 68, RFC 5234, 385 DOI 10.17487/RFC5234, January 2008, 386 . 388 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 389 of Named Entities (DANE) Transport Layer Security (TLS) 390 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 391 2012, . 393 Appendix A. Acknowledgements 395 Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ Housley 396 and Alessandro Vesely for comments on this document. 398 The editor of this document copied lots of text from RFC 2595 and RFC 399 6125, so the hard work of editors of these document is appreciated. 401 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 403 [[Note to RFC Editor: Please delete this section before publication]] 405 Added another example, clarified that subjectAltName and DNS SRV are 406 using slightly different syntax. 408 As any certificate can only include one CN-ID, corrected examples. 410 Split rules to talk seperately about requirements on MUAs, CAs and 411 MSPs/CSR generation tools. 413 Updated Introduction section. 415 Author's Address 417 Alexey Melnikov 418 Isode Ltd 419 14 Castle Mews 420 Hampton, Middlesex TW12 2NP 421 UK 423 EMail: Alexey.Melnikov@isode.com