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