idnits 2.17.1 draft-ietf-dane-openpgpkey-03.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 (April 01, 2015) is 3312 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2181' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC5233' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC7129' is defined on line 439, but no explicit reference was found in the text -- No information found for draft-dane-openpgpkey-usage - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track April 01, 2015 5 Expires: October 03, 2015 7 Using DANE to Associate OpenPGP public keys with email addresses 8 draft-ietf-dane-openpgpkey-03 10 Abstract 12 OpenPGP is a message format for email (and file) encryption that 13 lacks a standardized lookup mechanism to securely obtain OpenPGP 14 public keys. This document specifies a method for publishing, 15 locating and verifying OpenPGP public keys in DNS for a specific 16 email address using a new OPENPGPKEY DNS Resource Record. Security 17 is provided via DNSSEC. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 03, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 4 56 2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 4 57 2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 4 58 2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 4 59 3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 4 60 3.1. Email address variants . . . . . . . . . . . . . . . . . 5 61 4. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 6 62 4.1. Obtaining an OpenPGP key for a specific email address . . 6 63 4.2. Confirming the validity of an OpenPGP key . . . . . . . . 6 64 4.3. Verifying an unknown OpenPGP signature . . . . . . . . . 6 65 5. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 6.1. Response size . . . . . . . . . . . . . . . . . . . . . . 7 68 6.2. Email address information leak . . . . . . . . . . . . . 7 69 6.3. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 8 70 6.4. Forward security of OpenPGP versus DNSSEC . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 9.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 10 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 OpenPGP [RFC4880] public keys are used to encrypt or sign email 83 messages and files. To encrypt an email message, the sender's email 84 client or MTA needs to know where to find the recipient's OpenPGP 85 public key. Once obtained, it needs to find some proof that the 86 OpenPGP public key found actually belongs to the intended recipient. 88 Similarly, when files on a storage media are signed with an OpenPGP 89 public key that is included on the storage media, this key needs to 90 be independently verified. 92 Obtaining and verifying an OpenPGP public key is not a 93 straightforward process as there are no trusted standardized 94 locations for publishing OpenPGP public keys indexed by email 95 address. Instead, OpenPGP clients rely on "well-known key servers" 96 that are accessed using the HTTP Keyserver Protocol ("HKP") or 97 manually by users using a variety of differently formatted front-end 98 web pages. Worse, some OpenPGP users announce their OpenPGP public 99 key fingerprint on social media with no method of validation 100 whatsoever. 102 Currently deployed key servers have no method of validating any 103 uploaded OpenPGP public key. The key servers simply store and 104 publish. Anyone can add public keys with any identities and anyone 105 can add signatures to any other public key using forged malicious 106 identities. Furthermore, once uploaded, public keys cannot be 107 deleted. People who did not pre-sign a key revocation can never 108 remove their public key from these key servers once they lose their 109 private key. 111 The lack of a secure means to look up a public key for an email 112 address prevents email clients and MUAs from encrypting an outgoing 113 email to the target recipient, forcing the software to send the 114 message unencrypted. Currently deployed MTAs only support encrypting 115 the transport of the email, not the email contents itself, leaving 116 the content of the email exposed to anyone with access to any of the 117 mail or storage servers used to transport the email from the sender 118 to the receiver. 120 This document describes a mechanism to associate a user's OpenPGP 121 public key with their email address, using a new DNS RRtype. 123 The proposed new DNS Resource Record type is secured using DNSSEC. 124 This trust model is not meant to replace the Trust Signature model. 125 However, it can be used to encrypt a message that would otherwise 126 have to be sent out unencrypted, where it could be monitored by a 127 third party in transit or located in plaintext on a storage or email 128 server. This method can also be used to obtain the OpenPGP public 129 key which can then be used for manual verification. 131 1.1. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 This document also makes use of standard DNSSEC and DANE terminology. 138 See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for 139 these terms. 141 2. The OPENPGPKEY Resource Record 143 The OPENPGPKEY DNS resource record (RR) is used to associate an end 144 entity OpenPGP public key with an email address, thus forming a 145 "OpenPGP public key association". 147 The type value allocated for the OPENPGPKEY RR type is 61. The 148 OPENPGPKEY RR is class independent. The OPENPGPKEY RR has no special 149 TTL requirements. 151 2.1. The OPENPGPKEY RDATA component 153 The RDATA portion of an OPENPGPKEY Resource Record contains a single 154 value consisting of a [RFC4880] formatted OpenPGP public keyring. 156 2.2. The OPENPGPKEY RDATA wire format 158 The RDATA Wire Format consists of a single OpenPGP public key as 159 defined in Section 5.5.1.1 of [RFC4880]. Note that this format is 160 without ASCII armor or base64 encoding. 162 2.3. The OPENPGPKEY RDATA presentation format 164 The RDATA Presentation Format, as visible in textual zone files, 165 consists of a single OpenPGP public key as defined in 166 Section 5.5.1.1. of [RFC4880] encoded in base64 as defined in 167 Section 4 of [RFC4648]. 169 3. Location of the OPENPGPKEY record 171 The DNS does not allow the use of all characters that are supported 172 in the "local-part" of email addresses as defined in [RFC2822] and 173 [RFC6530]. Therefore, email addresses are mapped into DNS using the 174 following method: 176 o The user name (the "left-hand side" of the email address, called 177 the "local-part" in the mail message format definition [RFC2822] 178 and the "local part" in the specification for internationalized 179 email [RFC6530]) should already be encoded in UTF-8 (or its subset 180 ASCII). If it is written in another encoding it should be 181 converted to UTF-8. Next, it is turned into lowercase and hashed 182 using the SHA2-256 [RFC5754] algorithm, with the hash truncated to 183 28 octets and represented in its hexadecimal representation, to 184 become the left-most label in the prepared domain name. 185 Truncation comes from the right-most octets. This does not 186 include the at symbol ("@") that separates the left and right 187 sides of the email address. 189 o The string "_openpgpkey" becomes the second left-most label in the 190 prepared domain name. 192 o The domain name (the "right-hand side" of the email address, 193 called the "domain" in RFC 2822) is appended to the result of step 194 2 to complete the prepared domain name. 196 For example, to request an OPENPGPKEY resource record for a user 197 whose email address is "hugh@example.com", an OPENPGPKEY query would 198 be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35 199 eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The corresponding 200 RR in the example.com zone might look like (key shortened for 201 formatting): 203 c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY 205 3.1. Email address variants 207 Mail systems usually handle variant forms of local-parts. The most 208 common variants are upper and lower case, which are now invariably 209 treated as equivalent. But many other variants are possible. Some 210 systems allow and ignore "noise" characters such as dots, so local 211 parts johnsmith and John.Smith would be equivalent. Many systems 212 allow "extensions" such as john-ext or mary+ext where john or mary is 213 treated as the effective local-part, and the ext is passed to the 214 recipient for further handling. This can complicate finding the 215 OPENPGPKEY record associated with the dynamically created email 216 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. A client supporting OPENPGPKEY therefor MUST NOT perform 221 any kind of mapping rules based on the email address. As the local- 222 part is converted to lowercase before hashing, case sensitivity will 223 not cause problems for the OPENPGPKEY lookup. 225 4. Application use of OPENPGPKEY 227 The OPENPGPKEY record allows an application or service to obtain or 228 verify an OpenPGP public key. The lookup result MUST pass DNSSEC 229 validation; if validation reaches any state other than "Secure", the 230 verification MUST be treated as a failure. 232 4.1. Obtaining an OpenPGP key for a specific email address 234 If no OpenPGP public keys are known for an email address, an 235 OPENPGPKEY lookup can be performed to discover the OpenPGP public key 236 that belongs to a specific email address. This public key can then 237 be used to verify a received signed message or can be used to send 238 out an encrypted email message. 240 4.2. Confirming the validity of an OpenPGP key 242 Locally stored OpenPGP public keys are not automatically refreshed. 243 If the owner of that key creates a new OpenPGP public key, that owner 244 is unable to securely notify all users and applications that have its 245 old OpenPGP public key. Applications and users can perform an 246 OPENPGPKEY lookup to confirm the locally stored OpenPGP public key is 247 still the correct key to use. If verifying a locally stored OpenPGP 248 public key and the OpenPGP public key found through DNS is different 249 from the locally stored OpenPGP public key, the verification MUST be 250 treated as a failure. An application that can interact with the user 251 MAY ask the user for guidance. 253 4.3. Verifying an unknown OpenPGP signature 255 Storage media can be signed using an OpenPGP public key. Even if the 256 OpenPGP public key is included on the storage media, it needs to be 257 independently validated. OpenPGP public keys contain one or more IDs 258 than can have the syntax of an email address. An application can 259 perform a lookup for an OPENPGPKEY at the expected location for the 260 specific email address to confirm the validity of the OpenPGP public 261 key. Once the key has been validated, all files on the storage media 262 that have been signed by this key can now be verified. 264 5. OpenPGP Key size and DNS 266 Due to the expected size of the OPENPGPKEY record, it is recommended 267 to perform DNS queries for the OPENPGPKEY record using TCP, not UDP. 269 Although the reliability of the transport of large DNS Resource 270 Records has improved in the last years, it is still recommended to 271 keep the DNS records as small as possible without sacrificing the 272 security properties of the public key. The algorithm type and key 273 size of OpenPGP keys should not be modified to accommodate this 274 section. 276 OpenPGP supports various attributes that do not contribute to the 277 security of a key, such as an embedded image file. It is recommended 278 that these properties are not exported to OpenPGP public keyrings 279 that are used to create OPENPGPKEY Resource Records. Some OpenPGP 280 software, for example GnuPG, have support for a "minimal key export" 281 that is well suited to use as OPENPGPKEY RDATA. See Appendix A. 283 6. Security Considerations 285 OPENPGPKEY usage considerations are published in [OPENPGPKEY-USAGE]. 287 6.1. Response size 289 To prevent amplification attacks, an Authoritative DNS server MAY 290 wish to prevent returning OPENPGPKEY records over UDP unless the 291 source IP address has been verified with [DNS-COOKIES]. Such servers 292 MUST NOT return REFUSED, but answer the query with an empty Answer 293 Section and the truncation flag set ("TC=1"). 295 6.2. Email address information leak 297 Email addresses are not secret. Using them causes their publication. 298 The hashing of the user name in this document is not a security 299 feature. Publishing OPENPGPKEY records however, will create a list 300 of hashes of valid email addresses, which could simplify obtaining a 301 list of valid email addresses for a particular domain. It is 302 desirable to not ease the harvesting of email addresses where 303 possible. 305 The domain name part of the email address is not used as part of the 306 hash so that hashes can be used in multiple zones deployed using 307 DNAME [RFC6672]. This does makes it slightly easier and cheaper to 308 brute-force the SHA2-224 hashes into common and short user names, as 309 single rainbow tables can be re-used across domains. This can be 310 somewhat countered by using NSEC3. 312 DNS zones that are signed with DNSSEC using NSEC for denial of 313 existence are susceptible to zone-walking, a mechanism that allows 314 someone to enumerate all the OPENPGPKEY hashes in a zone. This can 315 be used in combination with previously hashed common or short user 316 names (in rainbow tables) to deduce valid email addresses. DNSSEC- 317 signed zones using NSEC3 for denial of existence instead of NSEC are 318 significantly harder to brute-force after performing a zone-walk. 320 6.3. Storage of OPENPGPKEY data 322 Users may have a local key store with OpenPGP public keys. An 323 application supporting the use of OPENPGPKEY DNS records MUST NOT 324 modify the local key store without explicit confirmation of the user, 325 as the application is unaware of the user's personal policy for 326 adding, removing or updating their local key store. An application 327 MAY warn the user if an OPENPGPKEY record does not match the OpenPGP 328 public key in the local key store. 330 OpenPGP public keys obtained via OPENPGPKEY records should not be 331 stored beyond their DNS TTL value. 333 6.4. Forward security of OpenPGP versus DNSSEC 335 DNSSEC key sizes are chosen based on the fact that these keys can be 336 rolled with next to no requirement for security in the future. If 337 one doubts the strength or security of the DNSSEC key for whatever 338 reason, one simply rolls to a new DNSSEC key with a stronger 339 algorithm or larger key size. On the other hand, OpenPGP key sizes 340 are chosen based on how many years (or decades) their encryption 341 should remain unbreakable by adversaries that own large scale 342 computational resources. 344 This effectively means that anyone who can obtain a DNSSEC private 345 key of a domain name via coercion, theft or brute force calculations, 346 can replace any OPENPGPKEY record in that zone and all of the 347 delegated child zones, irrespective of the key size of the OpenPGP 348 keypair. Any future messages encrypted with the malicious OpenPGP 349 key could then be read. 351 Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only 352 be trusted as much as the DNS domain can be trusted, and is no 353 substitute for in-person key verification of the "Web of Trust". See 354 [OPENPGPKEY-USAGE] for more in-depth information on safe usage of 355 OPENPGPKEY based OpenPGP keys. 357 7. IANA Considerations 359 7.1. OPENPGPKEY RRtype 361 This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has 362 been allocated by IANA from the Resource Record (RR) TYPEs 363 subregistry of the Domain Name System (DNS) Parameters registry. 365 8. Acknowledgments 366 This document is based on RFC-4255 and draft-ietf-dane-smime whose 367 authors are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur 368 Gudmundsson provided feedback and suggested various improvements. 369 Willem Toorop contributed the gpg and hexdump command options. Edwin 370 Taylor contributed language improvements for various iterations of 371 this document. Text regarding email mappings was taken from draft- 372 levine-dns-mailbox whose author is John Levine. 374 9. References 376 9.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 382 Rose, "DNS Security Introduction and Requirements", RFC 383 4033, March 2005. 385 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 386 Rose, "Resource Records for the DNS Security Extensions", 387 RFC 4034, March 2005. 389 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 390 Rose, "Protocol Modifications for the DNS Security 391 Extensions", RFC 4035, March 2005. 393 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 394 Encodings", RFC 4648, October 2006. 396 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 397 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 399 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 400 Message Syntax", RFC 5754, January 2010. 402 9.2. Informative References 404 [DNS-COOKIES] 405 Eastlake, Donald., "Domain Name System (DNS) Cookies", 406 draft-ietf-dnsop-cookies (work in progress), February 407 2015. 409 [OPENPGPKEY-USAGE] 410 Wouters, P., "Usage considerations with the DNS OPENPGPKEY 411 record", draft-dane-openpgpkey-usage (work in progress), 412 October 2014. 414 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 415 Specification", RFC 2181, July 1997. 417 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 418 2001. 420 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 421 (RR) Types", RFC 3597, September 2003. 423 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 424 Extension", RFC 5233, January 2008. 426 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 427 October 2008. 429 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 430 Internationalized Email", RFC 6530, February 2012. 432 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 433 DNS", RFC 6672, June 2012. 435 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 436 of Named Entities (DANE) Transport Layer Security (TLS) 437 Protocol: TLSA", RFC 6698, August 2012. 439 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 440 Existence in the DNS", RFC 7129, February 2014. 442 Appendix A. Generating OPENPGPKEY records 444 The commonly available GnuPG software can be used to generate the 445 RRdata portion of an OPENPGPKEY record: 447 gpg --export --export-options export-minimal \ 448 hugh@example.com | base64 450 The --armor or -a option of the gpg command should NOT be used, as it 451 adds additional markers around the armored key. 453 When DNS software reading or signing the zone file does not yet 454 support the OPENPGPKEY RRtype, the Generic Record Syntax of [RFC3597] 455 can be used to generate the RDATA. One needs to calculate the number 456 of octets and the actual data in hexadecimal: 458 gpg --export --export-options export-minimal \ 459 hugh@example.com | wc -c 461 gpg --export --export-options export-minimal \ 462 hugh@example.com | hexdump -e \ 463 '"\t" /1 "%.2x"' -e '/32 "\n"' 465 These values can then be used to generate a generic record (line 466 break has been added for formatting): 468 ._openpgpkey.example.com. IN TYPE61 \# \ 469 471 The openpgpkey command in the hash-slinger software can be used to 472 generate complete OPENPGPKEY records 474 ~> openpgpkey --output rfc hugh@example.com 475 c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...] 477 ~> openpgpkey --output generic hugh@example.com 478 c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...] 480 Author's Address 482 Paul Wouters 483 Red Hat 485 Email: pwouters@redhat.com