idnits 2.17.1 draft-ietf-uta-email-tls-certs-05.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 (September 20, 2015) is 3140 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 September 20, 2015 5 approved) 6 Intended status: Standards Track 7 Expires: March 23, 2016 9 Updated TLS Server Identity Check Procedure for Email Related Protocols 10 draft-ietf-uta-email-tls-certs-05 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 March 23, 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 . . . . . 4 57 5. Compliance Checklist for Mail Service Providers and 58 Certificate Signing Request generation tools . . . . . . . . 4 59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 66 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is 72 described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] 73 respectively. Each of the documents describes slightly different 74 rules for server certificate identity verification (or doesn't define 75 any rules at all). In reality, email client and server developers 76 implement many of these protocols at the same time, so it would be 77 good to define modern and consistent rules for verifying email server 78 identities using TLS. 80 This document describes the updated TLS server identity verification 81 procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], 82 POP [RFC1939] and ManageSieve [RFC5804] clients. It replaces 83 Section 2.4 of RFC 2595. 85 Note that this document doesn't apply to use of TLS in MTA-to-MTA 86 SMTP. 88 The main goal of the document is to provide consistent TLS server 89 identity verification procedure across multiple email related 90 protocols. This should make it easier for Certification Authorities 91 and ISPs to deploy TLS for email use, and would enable email client 92 developers to write more secure code. 94 2. Conventions Used in This Document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 The following terms or concepts are used through the document: 102 reference identifier: (as defined in [RFC6125]) One of the domain 103 names associated by the email (i.e., an SMTP, IMAP, POP3 or 104 ManageSieve) client with the destination email server and 105 optionally an application service type for performing name checks 106 on the server certificate. When name checks are applicable, at 107 least one of the reference identifiers MUST match an [RFC6125] 108 DNS-ID or SRV-ID (or if none are present the [RFC6125] CN-ID) of 109 the server certificate. 111 3. Email Server Certificate Verification Rules 113 During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 114 or ManageSieve client) MUST check its understanding of the server 115 hostname against the server's identity as presented in the server 116 Certificate message, in order to prevent man-in-the-middle attacks. 117 Matching is performed according to the rules specified in Section 6 118 of [RFC6125], including "certificate pinning" and the procedure on 119 failure to match. The following inputs are used by the verification 120 procedure used in [RFC6125]: 122 1. For DNS-ID and CN-ID identifier types the client MUST use one or 123 more of the following as "reference identifiers": (a) the right 124 hand side of the email address, (b) the hostname it used to open 125 the connection (without CNAME canonicalization). The client MAY 126 also use (c) a value securely derived from (a) or (b), such as 127 using "secure" DNSSEC validated lookup. 129 2. When using email service discovery procedure specified in 130 [RFC6186] the client MUST also use the right hand side of the 131 email address as another "reference identifier" to compare 132 against SRV-ID identifier in the server certificate. 134 The rules and guidelines defined in [RFC6125] apply to an email 135 server certificates, with the following supplemental rules: 137 1. Support for the DNS-ID identifier type (subjectAltName of dNSName 138 type [RFC5280]) is REQUIRED in Email client software 139 implementations. 141 2. Support for the SRV-ID identifier type (subjectAltName of SRVName 142 type [RFC4985]) is REQUIRED for email client software 143 implementations that support [RFC6186]. List of SRV-ID types for 144 email services is specified in [RFC6186]. For the ManageSieve 145 protocol the service name "sieve" is used. 147 3. URI-ID identifier type (subjectAltName of 148 uniformResourceIdentifier type [RFC5280]) MUST NOT be used by 149 clients for server verification, as URI-ID were not historically 150 used for email. 152 4. For backward compatibility with deployed software CN-ID 153 identifier type (CN attribute from the subject name, see 154 [RFC6125]) MAY be used for server identity verification. 156 5. Email protocols allow use of certain wilcards in identifiers 157 presented by email servers. The "*" wildcard character MAY be 158 used as the left-most name component of DNS-ID or CN-ID in the 159 certificate. For example, a DNS-ID of *.example.com would match 160 a.example.com, foo.example.com, etc. but would not match 161 example.com. Note that the wildcard character MUST NOT be used 162 as a fragment of the left-most name component (e.g., 163 *oo.example.com, f*o.example.com, or foo*.example.com). 165 4. Compliance Checklist for Certification Authorities 167 1. CA MUST support issuance of server certificates with DNS-ID 168 identifier type (subjectAltName of dNSName type [RFC5280]). 170 2. CA MUST support issuance of server certificates with SRV-ID 171 identifier type (subjectAltName of SRVName type [RFC4985]) for 172 each type of email service. 174 3. For backward compatibility with deployed client base, CA MUST 175 support issuance of server certificates with CN-ID identifier 176 type (CN attribute from the subject name, see [RFC6125]). 178 4. CA MAY allow "*" (wildcard) as the left-most name component of 179 DNS-ID or CN-ID in server certificates it issues. 181 5. Compliance Checklist for Mail Service Providers and Certificate 182 Signing Request generation tools 184 1. SHOULD include the DNS-ID identifier type (subjectAltName of 185 dNSName type [RFC5280]) in Certificate Signing Requests for both 186 the right hand side of served email addresses, as well as for the 187 host name where the email server(s) are running. 189 2. If the email services provided are discoverable using DNS SRV as 190 specified in [RFC6186], the Mail Service Provider MUST include 191 the SRV-ID identifier type (subjectAltName of SRVName type 192 [RFC4985]) for each type of email service in Certificate Signing 193 Requests. 195 3. SHOULD include CN-ID identifier type (CN attribute from the 196 subject name, see [RFC6125]) for the host name where the email 197 server(s) is running in Certificate Signing Requests for backward 198 compatibility with deployed email clients. (Note, a certificate 199 can only include a single CN-ID, so if a mail service is running 200 on multiple hosts, either each host has to use different 201 certificate with its own CN-ID, a single certificate with 202 multiple DNS-IDs, or a single certificate with wildcard in CN-ID 203 can be used). 205 4. MAY include "*" (wildcard) as the left-most name component of 206 DNS-ID or CN-ID in Certificate Signing Requests. 208 6. Examples 210 Consider an IMAP-accessible email server which supports both IMAP and 211 IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email 212 addresses of the form "user@example.net". A certificate for this 213 service needs to include DNS-IDs of "example.net" (because it is the 214 right hand side of emails) and "mail.example.net" (this is what a 215 user of this server enters manually, if not using [RFC6186]). It 216 might also include CN-IDs of "mail.example.net" for backward 217 compatibility with deployed infrastructure. 219 Consider the IMAP-accessible email server from the previous paragraph 220 which is additionally discoverable via DNS SRV lookups in domain 221 "example.net" (DNS SRV records "_imap._tcp.example.net" and 222 "_imaps._tcp.example.net"). In addition to DNS-ID/CN-ID identity 223 types specified above, a certificate for this service also needs to 224 include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the 225 IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). 226 See [RFC6186] for more details. (Note that unlike DNS SRV there is 227 no "_tcp" component in SRV-IDs). 229 Consider an SMTP Submission server at the host "submit.example.net" 230 servicing email addresses of the form "user@example.net" and 231 discoverable via DNS SRV lookups in domain "example.net" (DNS SRV 232 records "_submission._tcp.example.net"). A certificate for this 233 service needs to include SRV-IDs of "_submission.example.net" (see 234 [RFC6186]) along with DNS-IDs of "example.net" and 235 "submit.example.net". It might also include CN-IDs of 236 "submit.example.net" for backward compatibility with deployed 237 infrastructure. 239 Consider a host "mail.example.net" servicing email addresses of the 240 form "user@example.net" and discoverable via DNS SRV lookups in 241 domain "example.net", which runs SMTP Submission, IMAPS and POP3S 242 (POP3-over-TLS) and ManageSieve services. Each of the servers can 243 use their own certificate specific to their service (see examples 244 above). Alternatively they can all share a single certificate that 245 would include SRV-IDs of "_submission.example.net", 246 "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" 247 along with DNS-IDs of "example.net" and "mail.example.net". It might 248 also include CN-IDs of "mail.example.net" for backward compatibility 249 with deployed infrastructure. 251 7. IANA Considerations 253 This document doesn't require any action from IANA. 255 8. Security Considerations 257 The goal of this document is to improve interoperability and thus 258 security of email clients wishing to access email servers over TLS 259 protected email protocols, by specifying a consistent set of rules 260 that email service providers, email client writers and Certification 261 Authorities can use when creating server certificates. 263 TLS Server Identity Check for Email relies on use of trustworthy DNS 264 hostnames when constructing "reference identifiers" that are checked 265 against an email server certificate. Such trustworthy names are 266 either entered manually (for example if they are advertised on a Mail 267 Service Provider's website), explicitly confirmed by the user (e.g. 268 if they are a target of a DNS SRV lookup) or derived using a secure 269 third party service (e.g. DNSSEC-protected SRV records which are 270 verified by the client or trusted local resolver). Future work in 271 this area might benefit from integration with DANE [RFC6698], but it 272 is not covered by this document. 274 9. References 276 9.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 284 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 285 . 287 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 288 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 289 February 2002, . 291 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 292 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 293 . 295 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 296 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 297 . 299 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 300 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, 301 July 2010, . 303 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 304 Verification of Domain-Based Application Service Identity 305 within Internet Public Key Infrastructure Using X.509 306 (PKIX) Certificates in the Context of Transport Layer 307 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 308 2011, . 310 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 311 Housley, R., and W. Polk, "Internet X.509 Public Key 312 Infrastructure Certificate and Certificate Revocation List 313 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 314 . 316 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 317 Subject Alternative Name for Expression of Service Name", 318 RFC 4985, DOI 10.17487/RFC4985, August 2007, 319 . 321 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 322 Submission/Access Services", RFC 6186, 323 DOI 10.17487/RFC6186, March 2011, 324 . 326 9.2. Informative References 328 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 329 RFC 2595, DOI 10.17487/RFC2595, June 1999, 330 . 332 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 333 of Named Entities (DANE) Transport Layer Security (TLS) 334 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 335 2012, . 337 Appendix A. Acknowledgements 339 Thank you to Chris Newman, Viktor Dukhovni and Sean Turner for 340 comments on this document. 342 The editor of this document copied lots of text from RFC 2595 and RFC 343 6125, so the hard work of editors of these document is appreciated. 345 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 347 [[Note to RFC Editor: Please delete this section before publication]] 349 Added another example, clarified that subjectAltName and DNS SRV are 350 using slightly different syntax. 352 As any certificate can only include one CN-ID, corrected examples. 354 Split rules to talk seperately about requirements on MUAs, CAs and 355 MSPs/CSR generation tools. 357 Updated Introduction section. 359 Author's Address 361 Alexey Melnikov 362 Isode Ltd 363 14 Castle Mews 364 Hampton, Middlesex TW12 2NP 365 UK 367 EMail: Alexey.Melnikov@isode.com