idnits 2.17.1 draft-ietf-uta-email-tls-certs-07.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 9, 2015) is 3032 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 9, 2015 5 approved) 6 Intended status: Standards Track 7 Expires: June 11, 2016 9 Updated TLS Server Identity Check Procedure for Email Related Protocols 10 draft-ietf-uta-email-tls-certs-07 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 11, 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 Certification Authorities 5 58 5. Compliance Checklist for Mail Service Providers and 59 Certificate Signing Request generation tools . . . . . . . . 6 60 5.1. Notes on hosting multiple domains . . . . . . . . . . . . 6 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 9.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 68 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 11 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 [RFC4033][RFC4034][RFC4035] validated 153 lookup. 155 2. When using email service discovery procedure specified in 156 [RFC6186] the client MUST also use the domain portion of the 157 user's email address as another "reference identifier" to compare 158 against SRV-ID identifier in the server certificate. 160 The rules and guidelines defined in [RFC6125] apply to an email 161 server certificate, with the following supplemental rules: 163 1. Support for the DNS-ID identifier type (subjectAltName of dNSName 164 type [RFC5280]) is REQUIRED in Email client software 165 implementations. 167 2. Support for the SRV-ID identifier type (subjectAltName of SRVName 168 type [RFC4985]) is REQUIRED for email client software 169 implementations that support [RFC6186]. List of SRV-ID types for 170 email services is specified in [RFC6186]. For the ManageSieve 171 protocol the service name "sieve" is used. 173 3. URI-ID identifier type (subjectAltName of 174 uniformResourceIdentifier type [RFC5280]) MUST NOT be used by 175 clients for server verification, as URI-ID were not historically 176 used for email. 178 4. For backward compatibility with deployed software CN-ID 179 identifier type (CN attribute from the subject name, see 180 [RFC6125]) MAY be used for server identity verification. 182 5. Email protocols allow use of certain wilcards in identifiers 183 presented by email servers. The "*" wildcard character MAY be 184 used as the left-most name component of DNS-ID or CN-ID in the 185 certificate. For example, a DNS-ID of *.example.com would match 186 a.example.com, foo.example.com, etc. but would not match 187 example.com. Note that the wildcard character MUST NOT be used 188 as a fragment of the left-most name component (e.g., 189 *oo.example.com, f*o.example.com, or foo*.example.com). 191 4. Compliance Checklist for Certification Authorities 193 1. CA MUST support issuance of server certificates with DNS-ID 194 identifier type (subjectAltName of dNSName type [RFC5280]). 196 2. CA MUST support issuance of server certificates with SRV-ID 197 identifier type (subjectAltName of SRVName type [RFC4985]) for 198 each type of email service. See Section 4.1 for more discussion 199 on what this means for Certification Authorities. 201 3. For backward compatibility with deployed client base, CA MUST 202 support issuance of server certificates with CN-ID identifier 203 type (CN attribute from the subject name, see [RFC6125]). 205 4. CA MAY allow "*" (wildcard) as the left-most name component of 206 DNS-ID or CN-ID in server certificates it issues. 208 4.1. Notes on handling of SRV-ID by Certification Authorities 210 [RFC6186] provides an easy way for organizations to autoconfigure 211 email clients. It also allows for delegation of email services to an 212 email hosting provider. When connecting to such delegated hosting 213 service an email client that attempts to verify TLS server identity 214 needs to know that if it connects to imap.hosting.example.net that 215 such server is authorized to provide email access for an email such 216 as alice@example.org. In absence of SRV-IDs, users of compliant 217 email clients would be forced to manual confirm exception, because 218 TLS server certificate verification procedures specified in this 219 document would result in failure to match TLS server certificate 220 against the expected domains. One way to provide such authorization 221 is for the TLS certificate for imap.hosting.example.net to include 222 SRV-ID(s) (or DNS-ID) for example.org domain. (Another way is for 223 SRV lookups to be protected by DNSSEC, but this solution depends 224 reliance of DNSSEC and thus is not discussed in this document. A 225 future update to this document might rectify this.) 227 The ability of issuing certificates that contain SRV-ID implies the 228 ability to verify that entities requesting them are authorized to run 229 email service for these SRV-IDs. In particular, certification 230 authorities that can't verify such authorization MUST NOT include 231 email SRV-IDs in certificates they issue. This document doesn't 232 specify exact mechanism(s) that can be used to achieve this. 233 However, a few special case recommendations are listed below. 235 A certification authority willing to sign a certificate containing a 236 particular DNS-ID SHOULD also support signing a certificate 237 containing one or more of email SRV-IDs for the same domain, because 238 the SRV-ID effectively provides more restricted access to an email 239 service for the domain (as opposed to unrestricted use of any 240 services for the same domain, as specified by DNS-ID). 242 A certification authority which also provides DNS service for a 243 domain can use DNS information to validate SRV-IDs for the domain. 245 A certification authority MAY treat a certificate for a subdomain of 246 example.com (e.g. imap.sub1.example.com or imap.example.com) that 247 contains one or more SRV-ID for example.com as validated. 249 5. Compliance Checklist for Mail Service Providers and Certificate 250 Signing Request generation tools 252 1. MUST include the DNS-ID identifier type in Certificate Signing 253 Requests for the host name(s) where the email server(s) are 254 running. SHOULD include the DNS-ID identifier type in 255 Certificate Signing Requests for the domain portion of served 256 email addresses. 258 2. If the email services provided are discoverable using DNS SRV as 259 specified in [RFC6186], the Mail Service Provider MUST include 260 the SRV-ID identifier type for each type of email service in 261 Certificate Signing Requests. 263 3. SHOULD include CN-ID identifier type for the host name where the 264 email server(s) is running in Certificate Signing Requests for 265 backward compatibility with deployed email clients. (Note, a 266 certificate can only include a single CN-ID, so if a mail service 267 is running on multiple hosts, either each host has to use 268 different certificate with its own CN-ID, a single certificate 269 with multiple DNS-IDs, or a single certificate with wildcard in 270 CN-ID can be used). 272 4. MAY include "*" (wildcard) as the left-most name component of 273 DNS-ID or CN-ID in Certificate Signing Requests. 275 5.1. Notes on hosting multiple domains 277 A server that hosts multiple domains needs to do one of the following 278 (or some combination thereof): 280 1. Use a single TLS certificate that includes a complete list of all 281 the domains it is serving. 283 2. Serve each domain on its own IP/port, using separate TLS 284 certificates on each IP/port. 286 3. Use Server Name Indication (SNI) TLS extension [RFC6066] to 287 select the right certificate to return during TLS negotiation. 288 Each domain has its own TLS certificate in this case. 290 Each of these deployment choices have their scaling disadvantages 291 when the list of domains changes. A single certificate (the first 292 choice) requires that when a domain is added, then a new Certificate 293 Signing Request that includes a complete list of all the domains 294 needs to be issued and passed to a CA in order to generate a new 295 certificate. Separate IP/port can avoid regenerating the 296 certificate, but requires more transport layer resources. Use of TLS 297 SNI requires each email client to support it. 299 Several Mail Service Providers host hundreds and even thousands of 300 domain. This document, as well as its predecessors RFC 2595, RFC 301 3207, RFC 3501 and RFC 5804 don't address scaling issues caused by 302 use of TLS in multi-tenanted environments. Further work is needed to 303 address this issue, possibly using DNSSEC or something like POSH 304 [RFC7711]. 306 6. Examples 308 Consider an IMAP-accessible email server which supports both IMAP and 309 IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email 310 addresses of the form "user@example.net". A certificate for this 311 service needs to include DNS-IDs of "example.net" (because it is the 312 domain portion of emails) and "mail.example.net" (this is what a user 313 of this server enters manually, if not using [RFC6186]). It might 314 also include CN-ID of "mail.example.net" for backward compatibility 315 with deployed infrastructure. 317 Consider the IMAP-accessible email server from the previous paragraph 318 which is additionally discoverable via DNS SRV lookups in domain 319 "example.net" (DNS SRV records "_imap._tcp.example.net" and 320 "_imaps._tcp.example.net"). In addition to DNS-ID/CN-ID identity 321 types specified above, a certificate for this service also needs to 322 include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the 323 IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). 324 See [RFC6186] for more details. (Note that unlike DNS SRV there is 325 no "_tcp" component in SRV-IDs). 327 Consider the IMAP-accessible email server from the first paragraph 328 which is running on a host also known as "mycompany.example.com". In 329 addition to DNS-ID identity types specified above, a certificate for 330 this service also needs to include DNS-ID of "mycompany.example.com" 331 (this is what a user of this server enters manually, if not using 332 [RFC6186]). It might also include CN-ID of "mycompany.example.com" 333 instead of the CN-ID "mail.example.net" for backward compatibility 334 with deployed infrastructure. (This is so, because a certificate can 335 only include a single CN-ID) 337 Consider an SMTP Submission server at the host "submit.example.net" 338 servicing email addresses of the form "user@example.net" and 339 discoverable via DNS SRV lookups in domain "example.net" (DNS SRV 340 records "_submission._tcp.example.net"). A certificate for this 341 service needs to include SRV-IDs of "_submission.example.net" (see 342 [RFC6186]) along with DNS-IDs of "example.net" and 343 "submit.example.net". It might also include CN-ID of 344 "submit.example.net" for backward compatibility with deployed 345 infrastructure. 347 Consider a host "mail.example.net" servicing email addresses of the 348 form "user@example.net" and discoverable via DNS SRV lookups in 349 domain "example.net", which runs SMTP Submission, IMAPS and POP3S 350 (POP3-over-TLS) and ManageSieve services. Each of the servers can 351 use their own certificate specific to their service (see examples 352 above). Alternatively they can all share a single certificate that 353 would include SRV-IDs of "_submission.example.net", 354 "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" 355 along with DNS-IDs of "example.net" and "mail.example.net". It might 356 also include CN-ID of "mail.example.net" for backward compatibility 357 with deployed infrastructure. 359 7. IANA Considerations 361 This document doesn't require any action from IANA. 363 8. Security Considerations 365 The goal of this document is to improve interoperability and thus 366 security of email clients wishing to access email servers over TLS 367 protected email protocols, by specifying a consistent set of rules 368 that email service providers, email client writers and Certification 369 Authorities can use when creating server certificates. 371 TLS Server Identity Check for Email relies on use of trustworthy DNS 372 hostnames when constructing "reference identifiers" that are checked 373 against an email server certificate. Such trustworthy names are 374 either entered manually (for example if they are advertised on a Mail 375 Service Provider's website), explicitly confirmed by the user (e.g. 376 if they are a target of a DNS SRV lookup) or derived using a secure 377 third party service (e.g. DNSSEC-protected SRV records which are 378 verified by the client or trusted local resolver). Future work in 379 this area might benefit from integration with DANE [RFC6698], but it 380 is not covered by this document. 382 9. References 384 9.1. Normative References 386 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 387 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 388 . 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 396 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 397 February 2002, . 399 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 400 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 401 . 403 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 404 Subject Alternative Name for Expression of Service Name", 405 RFC 4985, DOI 10.17487/RFC4985, August 2007, 406 . 408 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 409 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, 410 July 2010, . 412 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 413 Housley, R., and W. Polk, "Internet X.509 Public Key 414 Infrastructure Certificate and Certificate Revocation List 415 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 416 . 418 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 419 Verification of Domain-Based Application Service Identity 420 within Internet Public Key Infrastructure Using X.509 421 (PKIX) Certificates in the Context of Transport Layer 422 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 423 2011, . 425 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 426 Submission/Access Services", RFC 6186, 427 DOI 10.17487/RFC6186, March 2011, 428 . 430 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 431 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 432 . 434 9.2. Informative References 436 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 437 RFC 2595, DOI 10.17487/RFC2595, June 1999, 438 . 440 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 441 Resource Identifier (URI): Generic Syntax", STD 66, 442 RFC 3986, DOI 10.17487/RFC3986, January 2005, 443 . 445 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 446 Rose, "DNS Security Introduction and Requirements", 447 RFC 4033, DOI 10.17487/RFC4033, March 2005, 448 . 450 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 451 Rose, "Resource Records for the DNS Security Extensions", 452 RFC 4034, DOI 10.17487/RFC4034, March 2005, 453 . 455 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 456 Rose, "Protocol Modifications for the DNS Security 457 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 458 . 460 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 461 Specifications: ABNF", STD 68, RFC 5234, 462 DOI 10.17487/RFC5234, January 2008, 463 . 465 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 466 Extensions: Extension Definitions", RFC 6066, 467 DOI 10.17487/RFC6066, January 2011, 468 . 470 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 471 of Named Entities (DANE) Transport Layer Security (TLS) 472 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 473 2012, . 475 [RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 476 (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, 477 . 479 Appendix A. Acknowledgements 481 Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ 482 Housley, Alessandro Vesely, Harald Alvestrand and John Levine for 483 comments on this document. 485 The editor of this document copied lots of text from RFC 2595 and RFC 486 6125, so the hard work of editors of these document is appreciated. 488 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 490 [[Note to RFC Editor: Please delete this section before publication]] 492 Added another example, clarified that subjectAltName and DNS SRV are 493 using slightly different syntax. 495 As any certificate can only include one CN-ID, corrected examples. 497 Split rules to talk seperately about requirements on MUAs, CAs and 498 MSPs/CSR generation tools. 500 Updated Introduction section. 502 Author's Address 504 Alexey Melnikov 505 Isode Ltd 506 14 Castle Mews 507 Hampton, Middlesex TW12 2NP 508 UK 510 EMail: Alexey.Melnikov@isode.com