idnits 2.17.1 draft-ietf-dane-smime-11.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 (July 8, 2016) is 2820 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: January 9, 2017 Kirei AB 6 July 8, 2016 8 Using Secure DNS to Associate Certificates with Domain Names For S/MIME 9 draft-ietf-dane-smime-11 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 January 9, 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 2. The SMIMEA Resource Record . . . . . . . . . . . . . . . . . 3 54 3. Email Addresses in Domain Names for S/MIME Certificate 55 Associations . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Email Address Variants and Internationalization 57 Considerations . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 5 59 6. Application Use of S/MIME Certificate Associations . . . . . 5 60 7. Certificate Size and DNS . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9.1. Email Address Information Leak . . . . . . . . . . . . . 7 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 S/MIME [RFC5751] messages often contain a certificate (some messages 71 contain more than one certificate). These certificates assist in 72 authenticating the sender of the message and can be used for 73 encrypting messages that will be sent in reply. In order for the S/ 74 MIME receiver to authenticate that a message is from the sender who 75 is identified in the message, the receiver's mail user agent (MUA) 76 must validate that this certificate is associated with the purported 77 sender. Currently, the MUA must trust a trust anchor upon which the 78 sender's certificate is rooted, and must successfully validate the 79 certificate. There are other requirements on the MUA, such as 80 associating the identity in the certificate with that of the message, 81 that are out of scope for this document. 83 Some people want to authenticate the association of the sender's 84 certificate with the sender without trusting a configured trust 85 anchor. Given that the DNS administrator for a domain name is 86 authorized to give identifying information about the zone, it makes 87 sense to allow that administrator to also make an authoritative 88 binding between email messages purporting to come from the domain 89 name and a certificate that might be used by someone authorized to 90 send mail from those servers. The easiest way to do this is to use 91 the DNS. 93 This document describes a mechanism for associating a user's 94 certificate with the domain that is similar to that described in DANE 95 itself [RFC6698], as updated by [RFC7218] and [RFC7671]. Most of the 96 operational and security considerations for using the mechanism in 97 this document are described in RFC 6698, and are not described here 98 at all. Only the major differences between this mechanism and those 99 used in RFC 6698 are described here. Thus, the reader must be 100 familiar with RFC 6698 before reading this document. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 This document also makes use of standard PKIX, DNSSEC, and S/MIME 109 terminology. See PKIX [RFC5280], DNSSEC [RFC4033], [RFC4034], 110 [RFC4035], and SMIME [RFC5751] for these terms. 112 2. The SMIMEA Resource Record 114 The SMIMEA DNS resource record (RR) is used to associate an end 115 entity certificate or public key with the associated email address, 116 thus forming a "SMIMEA certificate association". The semantics of 117 how the SMIMEA resource record is interpreted are given later in this 118 document. Note that the information returned in the SMIMEA record 119 might be for the end entity certificate, or it might be for the trust 120 anchor or an intermediate certificate. 122 The type value for the SMIMEA RRtype is defined in Section 8. The 123 SMIMEA resource record is class independent. The SMIMEA resource 124 record has no special TTL requirements. 126 The SMIMEA wire format and presentation format are the same as for 127 the TLSA record as described in section 2.1 of RFC 6698. The 128 certificate usage field, the selector field, and the matching type 129 field have the same format; the semantics are also the same except 130 where RFC 6698 talks about TLS at the target protocol for the 131 certificate information. 133 3. Email Addresses in Domain Names for S/MIME Certificate Associations 135 The DNS does not allow the use of all characters that are supported 136 in the "local-part" of email addresses as defined in [RFC5322] and 137 [RFC6530]. Therefore, email addresses are mapped into DNS using the 138 following method: 140 o The "left-hand side" of the email address, called the "local-part" 141 in both the mail message format definition [RFC5322] and in the 142 specification for internationalized email [RFC6530]) is encoded in 143 UTF-8 (or its subset ASCII). If the local-part is written in 144 another charset it MUST be converted to UTF-8. 146 o The local-part is first canonicalized using the following rules. 147 If the local-part is unquoted, any whitespace (CFWS) around dots 148 (".") is removed. Any enclosing double quotes are removed. Any 149 literal quoting is removed. 151 o If the local-part contains any non-ASCII characters, it SHOULD be 152 normalized using the Unicode Normalization Form C from 153 [Unicode52]. Recommended normalization rules can be found in 154 Section 10.1 of [RFC6530]. 156 o The local-part is hashed using the SHA2-256 [RFC5754] algorithm, 157 with the hash truncated to 28 octets and represented in its 158 hexadecimal representation, to become the left-most label in the 159 prepared domain name. 161 o The string "_smimecert" becomes the second left-most label in the 162 prepared domain name. 164 o The domain name (the "right-hand side" of the email address, 165 called the "domain" in [RFC5322]) is appended to the result of 166 step 2 to complete the prepared domain name. 168 For example, to request an SMIMEA resource record for a user whose 169 email address is "hugh@example.com", an SMIMEA query would be placed 170 for the following QNAME: "c93f1e400f26708f98cb19d936620da35eec8f72e57 171 f9eec01c1afd6._smimecert.example.com". 173 4. Email Address Variants and Internationalization Considerations 175 Mail systems usually handle variant forms of local-parts. The most 176 common variants are upper and lower case, often automatically 177 corrected when a name is recognized as such. Other variants include 178 systems that ignore "noise" characters such as dots, so that local 179 parts johnsmith and John.Smith would be equivalent. Many systems 180 allow "extensions" such as john-ext or mary+ext where john or mary is 181 treated as the effective local-part, and the ext is passed to the 182 recipient for further handling. This can complicate finding the 183 SMIMEA record associated with the dynamically created email address. 185 [RFC5321] and its predecessors have always made it clear that only 186 the recipient MTA is allowed to interpret the local-part of an 187 address. Therefor, sending MUAs and MTAs supporting this 188 specification MUST NOT perform any kind of mapping rules based on the 189 email address. In order to improve chances of finding SMIMEA 190 resource records for a particular local-part, domains that allow 191 variant forms (such as treating local-parts as case-insensitive) 192 might publish SMIMEA resource records for all variants of local- 193 parts, might publish variants on first use (for example a webmail 194 provider that also controls DNS for a domain can publish variants as 195 used by owner of a particular local-part) or just publish SMIMEA 196 resource records for the most common variants. 198 Section 3 above defines how the local-part is used to determine the 199 location in which one looks for an SMIMEA resource record. Given the 200 variety of local-parts seen in email, designing a good experiment for 201 this is difficult as: a) some current implementations are known to 202 lowercase at least US-ASCII local-parts, b) we know from (many) other 203 situations that any strategy based on guessing and making multiple 204 DNS queries is not going to achieve consensus for good reasons, and 205 c) the underlying issues are just hard - see Section 10.1 of 206 [RFC6530] for discussion of just some of the issues that would need 207 to be tackled to fully address this problem. 209 However, while this specification is not the place to try to address 210 these issues with local-parts, doing so is also not required to 211 determine the outcome of this experiment. If this experiment 212 succeeds then further work on email addresses with non-ASCII local- 213 parts will be needed and that would be better based on the findings 214 from this experiment, rather than doing nothing or starting this 215 experiment based on a speculative approach to what is a very complex 216 topic. 218 5. Mandatory-to-Implement Features 220 S/MIME MUAs conforming to this specification MUST be able to 221 correctly interpret SMIMEA records with certificate usages 0, 1, 2, 222 and 3. S/MIME MUAs conforming to this specification MUST be able to 223 compare a certificate association with a certificate offered by 224 another S/MIME MUA using selector types 0 and 1, and matching type 0 225 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to 226 make such comparisons with matching type 2 (SHA-512). 228 6. Application Use of S/MIME Certificate Associations 230 The SMIMEA record allows an application or service to obtain an S/ 231 MIME certificate or public key and use it for verifying a digital 232 signature or encrypting a message to the public key. The DNS answer 233 MUST pass DNSSEC validation; if DNSSEC validation reaches any state 234 other than "Secure" (as specified in [RFC4035]), the DNSSEC 235 validation MUST be treated as a failure. 237 If no S/MIME certificates are known for an email address, an SMIMEA 238 DNS lookup MAY be performed to seek the certificate or public key 239 that corresponds to that email address. This can then be used to 240 verify a received signed message or can be used to send out an 241 encrypted email message. An application whose attempt fails to 242 retrieve a DNSSEC verified SMIMEA resource record from the DNS should 243 remember that failure for some time to avoid sending out a DNS 244 request for each email message the application is sending out; such 245 DNS requests constitute a privacy leak. 247 7. Certificate Size and DNS 249 Due to the expected size of the SMIMEA record, applications SHOULD 250 use TCP - not UDP - to perform queries for the SMIMEA resource 251 record. 253 Although the reliability of the transport of large DNS resource 254 records has improved in the last years, it is still recommended to 255 keep the DNS records as small as possible without sacrificing the 256 security properties of the public key. The algorithm type and key 257 size of certificates should not be modified to accommodate this 258 section. 260 8. IANA Considerations 262 This document uses a new DNS RRtype, SMIMEA, whose value (53) was 263 allocated by IANA from the Resource Record (RR) TYPEs subregistry of 264 the Domain Name System (DNS) Parameters registry. 266 9. Security Considerations 268 Client treatment of any information included in the trust anchor is a 269 matter of local policy. This specification does not mandate that 270 such information be inspected or validated by the domain name 271 administrator. 273 DNSSEC does not protect the queries from Pervasive Monitoring as 274 defined in [RFC7258]. Since DNS queries are currently mostly 275 unencrypted, a query to lookup a target SMIMEA record could reveal 276 that a user using the (monitored) recursive DNS server is attempting 277 to send encrypted email to a target. 279 Various components could be responsible for encrypting an email 280 message to a target recipient. It could be done by the sender's MUA 281 or a MUA plugin or the sender's MTA. Each of these have their own 282 characteristics. A MUA can ask the user to make a decision before 283 continuing. The MUA can either accept or refuse a message. The MTA 284 must deliver the message as-is, or encrypt the message before 285 delivering. Each of these components should attempt to encrypt an 286 unencrypted outgoing message whenever possible. 288 In theory, two different local-parts could hash to the same value. 289 This document assumes that such a hash collision has a negliable 290 chance of happening. 292 Organisations that are required to be able to read everyone's 293 encrypted email should publish the escrow key as the SMIMEA record. 294 Mail servers of such organizations MAY optionally re-encrypt the 295 message to the individual's S/MIME key. 297 If an obtained S/MIME certificate is revoked or expired, that 298 certificate MUST not be used, even if that would result in sending a 299 message in plaintext. 301 Anyone who can obtain a DNSSEC private key of a domain name via 302 coercion, theft or brute force calculations, can replace any SMIMEA 303 record in that zone and all of the delegated child zones. Any future 304 messages encrypted with the malicious SMIMEA key could then be read. 305 Therefore, an certificate or key obtained from a DNSSEC validated 306 SMIMEA record can only be trusted as much as the DNS domain can be 307 trusted. 309 9.1. Email Address Information Leak 311 The hashing of the local-part in this document is not a security 312 feature. Publishing SMIMEA records will create a list of hashes of 313 valid email addresses, which could simplify obtaining a list of valid 314 email addresses for a particular domain. It is desirable to not ease 315 the harvesting of email addresses where possible. 317 The domain name part of the email address is not used as part of the 318 hash so that hashes can be used in multiple zones deployed using 319 DNAME [RFC6672]. This does makes it slightly easier and cheaper to 320 brute-force the SHA2-256 hashes into common and short local-parts, as 321 single rainbow tables can be re-used across domains. This can be 322 somewhat countered by using NSEC3. 324 DNS zones that are signed with DNSSEC using NSEC for denial of 325 existence are susceptible to zone-walking, a mechanism that allows 326 someone to enumerate all the SMIMEA hashes in a zone. This can be 327 used in combination with previously hashed common or short local- 328 parts (in rainbow tables) to deduce valid email addresses. DNSSEC- 329 signed zones using NSEC3 for denial of existence instead of NSEC are 330 significantly harder to brute-force after performing a zone-walk. 332 10. Acknowledgements 334 A great deal of material in this document is copied from RFC-to-be 335 draft-ietf-dane-openpgpkey-12. That material was created by Paul 336 Wouters and other participants in the IETF DANE WG. 338 Brian Dickson, Miek Gieben, and Martin Pels contributed technical 339 ideas and support to this document. 341 11. References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 349 Rose, "DNS Security Introduction and Requirements", 350 RFC 4033, DOI 10.17487/RFC4033, March 2005, 351 . 353 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 354 Rose, "Resource Records for the DNS Security Extensions", 355 RFC 4034, DOI 10.17487/RFC4034, March 2005, 356 . 358 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 359 Rose, "Protocol Modifications for the DNS Security 360 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 361 . 363 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 364 Housley, R., and W. Polk, "Internet X.509 Public Key 365 Infrastructure Certificate and Certificate Revocation List 366 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 367 . 369 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 370 DOI 10.17487/RFC5321, October 2008, 371 . 373 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 374 DOI 10.17487/RFC5322, October 2008, 375 . 377 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 378 Mail Extensions (S/MIME) Version 3.2 Message 379 Specification", RFC 5751, DOI 10.17487/RFC5751, January 380 2010, . 382 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 383 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 384 2010, . 386 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 387 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 388 February 2012, . 390 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 391 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 392 . 394 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 395 of Named Entities (DANE) Transport Layer Security (TLS) 396 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 397 2012, . 399 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 400 Conversations about DNS-Based Authentication of Named 401 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 402 2014, . 404 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 405 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 406 2014, . 408 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 409 Authentication of Named Entities (DANE) Protocol: Updates 410 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 411 October 2015, . 413 [Unicode52] 414 The Unicode Consortium, "The Unicode Standard, Version 415 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", 416 (Mountain View, CA: The Unicode Consortium, 2009. ISBN 417 978-1-936213-00-9).", October 2009. 419 Authors' Addresses 421 Paul Hoffman 422 ICANN 424 Email: paul.hoffman@icann.org 425 Jakob Schlyter 426 Kirei AB 428 Email: jakob@kirei.se