idnits 2.17.1 draft-ietf-dane-smime-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 16, 2017) is 2597 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Experimental J. Schlyter 5 Expires: September 17, 2017 Kirei AB 6 March 16, 2017 8 Using Secure DNS to Associate Certificates with Domain Names For S/MIME 9 draft-ietf-dane-smime-16 11 Abstract 13 This document describes how to use secure DNS to associate an S/MIME 14 user's certificate with the intended domain name, similar to the way 15 that DNS-Based Authentication of Named Entities (DANE), RFC 6698, 16 does for TLS. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 17, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Experiment Goal . . . . . . . . . . . . . . . . . . . . . 3 55 2. The SMIMEA Resource Record . . . . . . . . . . . . . . . . . 4 56 3. Location of the SMIMEA Record . . . . . . . . . . . . . . . . 4 57 4. Email Address Variants and Internationalization 58 Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 6 60 6. Application Use of S/MIME Certificate Associations . . . . . 6 61 7. Certificate Size and DNS . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 9.1. Response Size . . . . . . . . . . . . . . . . . . . . . . 8 65 9.2. Email Address Information Leak . . . . . . . . . . . . . 8 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 11.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 S/MIME [RFC5751] messages often contain a certificate (some messages 75 contain more than one certificate). These certificates assist in 76 authenticating the sender of the message and can be used for 77 encrypting messages that will be sent in reply. In order for the S/ 78 MIME receiver to authenticate that a message is from the sender who 79 is identified in the message, the receiver's mail user agent (MUA) 80 must validate that this certificate is associated with the purported 81 sender. Currently, the MUA must trust a trust anchor upon which the 82 sender's certificate is rooted, and must successfully validate the 83 certificate. There are other requirements on the MUA, such as 84 associating the identity in the certificate with that of the message, 85 that are out of scope for this document. 87 Some people want to authenticate the association of the sender's 88 certificate with the sender without trusting a configured trust 89 anchor. Others to want mitigate the difficulty of finding 90 certificates from outside the enterprise. Given that the DNS 91 administrator for a domain name is authorized to give identifying 92 information about the zone, it makes sense to allow that 93 administrator to also make an authoritative binding between email 94 messages purporting to come from the domain name and a certificate 95 that might be used by someone authorized to send mail from those 96 servers. The easiest way to do this is to use the DNS. 98 This document describes a mechanism for associating a user's 99 certificate with the domain that is similar to that described in DANE 100 itself [RFC6698], as updated by [RFC7218] and [RFC7671]; it is also 101 similar to the mechanism given in [RFC7929] for OpenPGP. Most of the 102 operational and security considerations for using the mechanism in 103 this document are described in RFC 6698, and are not described here 104 at all. Only the major differences between this mechanism and those 105 used in RFC 6698 are described here. Thus, the reader must be 106 familiar with RFC 6698 before reading this document. 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This document also makes use of standard PKIX, DNSSEC, and S/MIME 115 terminology. See PKIX [RFC5280], DNSSEC [RFC4033], [RFC4034], 116 [RFC4035], and SMIME [RFC5751] for these terms. 118 1.2. Experiment Goal 120 This specification is one experiment in improving access to public 121 keys for end-to-end email security. There are a range of ways in 122 which this can reasonably be done for OpenPGP or S/MIME, for example, 123 using the DNS, or SMTP, or HTTP. Proposals for each of these have 124 been made with various levels of support in terms of implementation 125 and deployment. For each such experiment, specifications such as 126 this will enable experiments to be carried out that may succeed or 127 that may uncover technical or other impediments to large- or small- 128 scale deployments. The IETF encourages those implementing and 129 deploying such experiments to publicly document their experiences so 130 that future specifications in this space can benefit. 132 This document defines an RRtype whose use is Experimental. The goal 133 of the experiment is to see whether encrypted email usage will 134 increase if an automated discovery method is available to MTAs and 135 MUAs to help the end user with email encryption key management. 137 It is unclear if this RRtype will scale to some of the larger email 138 service deployments. Concerns have been raised about the size of the 139 SMIMEA record and the size of the resulting DNS zone files. This 140 experiment hopefully will give the working group some insight into 141 whether or not this is a problem. 143 If the experiment is successful, it is expected that the findings of 144 the experiment will result in an updated document for standards track 145 approval. 147 2. The SMIMEA Resource Record 149 The SMIMEA DNS resource record (RR) is used to associate an end 150 entity certificate or public key with the associated email address, 151 thus forming a "SMIMEA certificate association". The semantics of 152 how the SMIMEA resource record is interpreted are given later in this 153 document. Note that the information returned in the SMIMEA record 154 might be for the end entity certificate, or it might be for the trust 155 anchor or an intermediate certificate. This mechanism is similar to 156 the one given in [RFC7929] for OpenPGP. 158 The type value for the SMIMEA RRtype is defined in Section 8. The 159 SMIMEA resource record is class independent. 161 The SMIMEA wire format and presentation format are the same as for 162 the TLSA record as described in section 2.1 of [RFC6698]. The 163 certificate usage field, the selector field, and the matching type 164 field have the same format; the semantics are also the same except 165 where RFC 6698 talks about TLS at the target protocol for the 166 certificate information. 168 3. Location of the SMIMEA Record 170 The DNS does not allow the use of all characters that are supported 171 in the "local-part" of email addresses as defined in [RFC5322] and 172 [RFC6530]. Therefore, email addresses are mapped into DNS using the 173 following method: 175 1. The "left-hand side" of the email address, called the "local- 176 part" in both the mail message format definition [RFC5322] and in 177 the specification for internationalized email [RFC6530]) is 178 encoded in UTF-8 (or its subset ASCII). If the local-part is 179 written in another charset it MUST be converted to UTF-8. 181 2. The local-part is first canonicalized using the following rules. 182 If the local-part is unquoted, any whitespace (CFWS) around dots 183 (".") is removed. Any enclosing double quotes are removed. Any 184 literal quoting is removed. 186 3. If the local-part contains any non-ASCII characters, it SHOULD be 187 normalized using the Unicode Normalization Form C from 188 [Unicode52]. Recommended normalization rules can be found in 189 Section 10.1 of [RFC6530]. 191 4. The local-part is hashed using the SHA2-256 [RFC5754] algorithm, 192 with the hash truncated to 28 octets and represented in its 193 hexadecimal representation, to become the left-most label in the 194 prepared domain name. 196 5. The string "_smimecert" becomes the second left-most label in the 197 prepared domain name. 199 6. The domain name (the "right-hand side" of the email address, 200 called the "domain" in [RFC5322]) is appended to the result of 201 step 5 to complete the prepared domain name. 203 For example, to request an SMIMEA resource record for a user whose 204 email address is "hugh@example.com", an SMIMEA query would be placed 205 for the following QNAME: "c93f1e400f26708f98cb19d936620da35eec8f72e57 206 f9eec01c1afd6._smimecert.example.com". 208 4. Email Address Variants and Internationalization Considerations 210 Mail systems usually handle variant forms of local-parts. The most 211 common variants are upper and lower case, often automatically 212 corrected when a name is recognized as such. Other variants include 213 systems that ignore "noise" characters such as dots, so that local 214 parts johnsmith and John.Smith would be equivalent. Many systems 215 allow "extensions" such as john-ext or mary+ext where john or mary is 216 treated as the effective local-part, and the ext is passed to the 217 recipient for further handling. This can complicate finding the 218 SMIMEA record associated with the dynamically created email address. 220 [RFC5321] and its predecessors have always made it clear that only 221 the recipient MTA is allowed to interpret the local-part of an 222 address. Therefor, sending MUAs and MTAs supporting this 223 specification MUST NOT perform any kind of mapping rules based on the 224 email address. In order to improve chances of finding SMIMEA 225 resource records for a particular local-part, domains that allow 226 variant forms (such as treating local-parts as case-insensitive) 227 might publish SMIMEA resource records for all variants of local- 228 parts, might publish variants on first use (for example a webmail 229 provider that also controls DNS for a domain can publish variants as 230 used by owner of a particular local-part) or just publish SMIMEA 231 resource records for the most common variants. 233 Section 3 above defines how the local-part is used to determine the 234 location in which one looks for an SMIMEA resource record. Given the 235 variety of local-parts seen in email, designing a good experiment for 236 this is difficult as: a) some current implementations are known to 237 lowercase at least US-ASCII local-parts, b) we know from (many) other 238 situations that any strategy based on guessing and making multiple 239 DNS queries is not going to achieve consensus for good reasons, and 240 c) the underlying issues are just hard - see Section 10.1 of 241 [RFC6530] for discussion of just some of the issues that would need 242 to be tackled to fully address this problem. 244 However, while this specification is not the place to try to address 245 these issues with local-parts, doing so is also not required to 246 determine the outcome of this experiment. If this experiment 247 succeeds then further work on email addresses with non-ASCII local- 248 parts will be needed and that would be better based on the findings 249 from this experiment, rather than doing nothing or starting this 250 experiment based on a speculative approach to what is a very complex 251 topic. 253 5. Mandatory-to-Implement Features 255 S/MIME MUAs conforming to this specification MUST be able to 256 correctly interpret SMIMEA records with certificate usages 0, 1, 2, 257 and 3. S/MIME MUAs conforming to this specification MUST be able to 258 compare a certificate association with a certificate offered by 259 another S/MIME MUA using selector types 0 and 1, and matching type 0 260 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to 261 make such comparisons with matching type 2 (SHA-512). 263 S/MIME MUAs conforming to this specification MUST be able to 264 interpret any S/MIME capabilities (defined in [RFC4262]) in any 265 certificates that it receives through SMIMEA records. 267 6. Application Use of S/MIME Certificate Associations 269 The SMIMEA record allows an application or service to obtain an S/ 270 MIME certificate or public key and use it for verifying a digital 271 signature or encrypting a message to the public key. The DNS answer 272 MUST pass DNSSEC validation; if DNSSEC validation reaches any state 273 other than "Secure" (as specified in [RFC4035]), the DNSSEC 274 validation MUST be treated as a failure. 276 If no S/MIME certificates are known for an email address, an SMIMEA 277 DNS lookup MAY be performed to seek the certificate or public key 278 that corresponds to that email address. This can then be used to 279 verify a received signed message or can be used to send out an 280 encrypted email message. An application whose attempt fails to 281 retrieve a DNSSEC verified SMIMEA resource record from the DNS should 282 remember that failure for some time to avoid sending out a DNS 283 request for each email message the application is sending out; such 284 DNS requests constitute a privacy leak. 286 7. Certificate Size and DNS 288 Due to the expected size of the SMIMEA record, applications SHOULD 289 use TCP - not UDP - to perform queries for the SMIMEA resource 290 record. 292 Although the reliability of the transport of large DNS resource 293 records has improved in the last years, it is still recommended to 294 keep the DNS records as small as possible without sacrificing the 295 security properties of the public key. The algorithm type and key 296 size of certificates should not be modified to accommodate this 297 section. 299 8. IANA Considerations 301 This document uses a new DNS RRtype, SMIMEA, whose value (53) was 302 allocated by IANA from the Resource Record (RR) TYPEs subregistry of 303 the Domain Name System (DNS) Parameters registry. 305 9. Security Considerations 307 Client treatment of any information included in the trust anchor is a 308 matter of local policy. This specification does not mandate that 309 such information be inspected or validated by the domain name 310 administrator. 312 DNSSEC does not protect the queries from Pervasive Monitoring as 313 defined in [RFC7258]. Since DNS queries are currently mostly 314 unencrypted, a query to lookup a target SMIMEA record could reveal 315 that a user using the (monitored) recursive DNS server is attempting 316 to send encrypted email to a target. 318 Various components could be responsible for encrypting an email 319 message to a target recipient. It could be done by the sender's MUA 320 or a MUA plugin or the sender's MTA. Each of these have their own 321 characteristics. A MUA can ask the user to make a decision before 322 continuing. The MUA can either accept or refuse a message. The MTA 323 might deliver the message as-is, or encrypt the message before 324 delivering. Each of these components should attempt to encrypt an 325 unencrypted outgoing message whenever possible. 327 In theory, two different local-parts could hash to the same value. 328 This document assumes that such a hash collision has a negliable 329 chance of happening. 331 If an obtained S/MIME certificate is revoked or expired, that 332 certificate MUST NOT be used, even if that would result in sending a 333 message in plaintext. 335 Anyone who can obtain a DNSSEC private key of a domain name via 336 coercion, theft or brute force calculations, can replace any SMIMEA 337 record in that zone and all of the delegated child zones. Any future 338 messages encrypted with the malicious SMIMEA key could then be read. 339 Therefore, an certificate or key obtained from a DNSSEC validated 340 SMIMEA record can only be trusted as much as the DNS domain can be 341 trusted. 343 Organisations that are required to be able to read everyone's 344 encrypted email should publish the escrow key as the SMIMEA record. 345 Mail servers of such organizations MAY optionally re-encrypt the 346 message to the individual's S/MIME key. This case can be considered 347 a special case of the key-replacement attack described above. 349 9.1. Response Size 351 To prevent amplification attacks, an Authoritative DNS server MAY 352 wish to prevent returning SMIMEA records over UDP unless the source 353 IP address has been confirmed with [RFC7873]. If a query is received 354 via UDP without source IP address verification, the server MUST NOT 355 return REFUSED, but answer the query with an empty answer section and 356 the truncation flag set ("TC=1"). 358 9.2. Email Address Information Leak 360 The hashing of the local-part in this document is not a security 361 feature. Publishing SMIMEA records will create a list of hashes of 362 valid email addresses, which could simplify obtaining a list of valid 363 email addresses for a particular domain. It is desirable to not ease 364 the harvesting of email addresses where possible. 366 The domain name part of the email address is not used as part of the 367 hash so that hashes can be used in multiple zones deployed using 368 DNAME [RFC6672]. This makes it slightly easier and cheaper to brute- 369 force the SHA2-256 hashes into common and short local-parts, as 370 single rainbow tables [Rainbow] can be re-used across domains. This 371 can be somewhat countered by using NSEC3 [RFC5155]. 373 DNS zones that are signed with DNSSEC using NSEC [RFC4033] for denial 374 of existence are susceptible to zone-walking, a mechanism that allows 375 someone to enumerate all the SMIMEA hashes in a zone. This can be 376 used in combination with previously hashed common or short local- 377 parts (in rainbow tables) to deduce valid email addresses. DNSSEC- 378 signed zones using NSEC3 for denial of existence instead of NSEC are 379 significantly harder to brute-force after performing a zone-walk. 381 10. Acknowledgements 383 A great deal of material in this document is copied from [RFC7929]. 384 That material was created by Paul Wouters and other participants in 385 the IETF DANE WG. 387 Brian Dickson, Stephen Farrell, Miek Gieben, and Martin Pels, and Jim 388 Schaad contributed technical ideas and support to this document. 390 11. References 392 11.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 400 Rose, "DNS Security Introduction and Requirements", 401 RFC 4033, DOI 10.17487/RFC4033, March 2005, 402 . 404 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 405 Rose, "Resource Records for the DNS Security Extensions", 406 RFC 4034, DOI 10.17487/RFC4034, March 2005, 407 . 409 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 410 Rose, "Protocol Modifications for the DNS Security 411 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 412 . 414 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 415 Housley, R., and W. Polk, "Internet X.509 Public Key 416 Infrastructure Certificate and Certificate Revocation List 417 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 418 . 420 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 421 Mail Extensions (S/MIME) Version 3.2 Message 422 Specification", RFC 5751, DOI 10.17487/RFC5751, January 423 2010, . 425 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 426 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 427 2010, . 429 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 430 of Named Entities (DANE) Transport Layer Security (TLS) 431 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 432 2012, . 434 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 435 Authentication of Named Entities (DANE) Protocol: Updates 436 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 437 October 2015, . 439 11.2. Informative References 441 [Rainbow] Oechslin, P., "Making a Faster Cryptanalytic Time-Memory 442 Trade-Off", 2003, 443 . 446 [RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ 447 Multipurpose Internet Mail Extensions (S/MIME) 448 Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 449 2005, . 451 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 452 Security (DNSSEC) Hashed Authenticated Denial of 453 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 454 . 456 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 457 DOI 10.17487/RFC5321, October 2008, 458 . 460 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 461 DOI 10.17487/RFC5322, October 2008, 462 . 464 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 465 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 466 February 2012, . 468 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 469 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 470 . 472 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 473 Conversations about DNS-Based Authentication of Named 474 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 475 2014, . 477 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 478 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 479 2014, . 481 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 482 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 483 . 485 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 486 (DANE) Bindings for OpenPGP", RFC 7929, 487 DOI 10.17487/RFC7929, August 2016, 488 . 490 [Unicode52] 491 The Unicode Consortium, "The Unicode Standard, Version 492 6.1.0, defined by: "The Unicode Standard, Version 6.1.0", 493 (Mountain View, CA: The Unicode Consortium, 2009. ISBN 494 978-1-936213-02-3).", 2012. 496 Authors' Addresses 498 Paul Hoffman 499 ICANN 501 Email: paul.hoffman@icann.org 503 Jakob Schlyter 504 Kirei AB 506 Email: jakob@kirei.se