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