idnits 2.17.1 draft-ietf-dane-openpgpkey-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2015) is 3335 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 341, 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 (~~), 2 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 March 09, 2015 5 Expires: September 10, 2015 7 Using DANE to Associate OpenPGP public keys with email addresses 8 draft-ietf-dane-openpgpkey-02 10 Abstract 12 OpenPGP is a message format for email (and file) encryption, that 13 lacks a standardized lookup mechanism to obtain OpenPGP public keys. 14 This document specifies a method for securely publishing and locating 15 OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource 16 Record. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 10, 2015. 35 Copyright Notice 37 Copyright (c) 2015 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 2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 3 55 2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 3 56 2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 3 57 2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 4 58 3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 4 59 3.1. Email address variants . . . . . . . . . . . . . . . . . 4 60 4. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5.1. Response size . . . . . . . . . . . . . . . . . . . . . . 5 63 5.2. Email address information leak . . . . . . . . . . . . . 5 64 5.3. Forward security of OpenPGP versus DNSSEC . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 To encrypt a message to a target recipient using OpenPGP [RFC4880], 77 possession of the recipient's OpenPGP public key is required. To 78 obtain that public key, the sender's email client or MTA needs to 79 know where to find the recipient's public key. Once obtained, it 80 needs to find some proof that the public key found actually belongs 81 to the intended recipient. 83 Obtaining a public key is not a straightforward process as there are 84 no trusted standardized locations for publishing OpenPGP public keys 85 indexed by email address. Instead, OpenPGP clients rely on "well- 86 known key servers" that are accessed using the HTTP Keyserver 87 Protocol ("HKP") or manually by users using a variety of differently 88 formatted front-end web pages. 90 Currently deployed key servers have no method of validating any 91 uploaded OpenPGP public key. The key servers simply store and 92 publish. Anyone can add public keys with any identities and anyone 93 can add signatures to any other public key using forged malicious 94 identities. Furthermore, once uploaded, public keys cannot be 95 deleted. People who did not pre-sign a key revocation can never 96 remove their public key from these key servers once they lose their 97 private key. 99 The lack of a secure means to look up a public key for an email 100 address also prevents email clients and MUAs from encrypting a 101 received email to the target recipient, forcing the software to send 102 the message unencrypted. Currently deployed MTAs only support 103 encrypting the transport of the email, not the email contents itself. 105 This document describes a mechanism to associate a user's OpenPGP 106 public key with their email address, using a new DNS RRtype. 108 The proposed new DNS Resource Record type is secured using DNSSEC. 109 This trust model is not meant to replace the Trust Signature model. 110 However, it can be used to encrypt a message that would otherwise 111 have to be sent out unencrypted, where it could be monitored by a 112 third party in transit or located in plaintext on a storage or email 113 server. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 This document also makes use of standard DNSSEC and DANE terminology. 122 See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for 123 these terms. 125 2. The OPENPGPKEY Resource Record 127 The OPENPGPKEY DNS resource record (RR) is used to associate an end 128 entity OpenPGP public key with an email address, thus forming a 129 "OpenPGP public key association". 131 The type value allocated for the OPENPGPKEY RR type is 61. The 132 OPENPGPKEY RR is class independent. The OPENPGPKEY RR has no special 133 TTL requirements. 135 2.1. The OPENPGPKEY RDATA component 137 The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single 138 value consisting of a [RFC4880] formatted OpenPGP public keyring. 140 2.2. The OPENPGPKEY RDATA wire format 142 The RDATA Wire Format consists of a single OpenPGP public key as 143 defined in Section 5.5.1.1 of [RFC4880]. Note that this format is 144 without ASCII armor or base64 encoding. 146 2.3. The OPENPGPKEY RDATA presentation format 148 The RDATA Presentation Format, as visible in textual zone files, 149 consists of a single OpenPGP public key as defined in 150 Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648] 152 3. Location of the OPENPGPKEY record 154 The DNS does not allow the use of all characters that are supported 155 in the "local-part" of email addresses as defined in [RFC2822] and 156 [RFC6530]. Therefore, email addresses are mapped into DNS using the 157 following method: 159 o The user name (the "left-hand side" of the email address, called 160 the "local-part" in the mail message format definition [RFC2822] 161 and the "local part" in the specification for internationalized 162 email [RFC6530]), is hashed using the SHA2-224 [RFC5754] 163 algorithm, with the hash being represented in its hexadecimal 164 representation, to become the left-most label in the prepared 165 domain name. This does not include the at symbol ("@") that 166 separates the left and right sides of the email address. 168 o The string "_openpgpkey" becomes the second left-most label in the 169 prepared domain name. 171 o The domain name (the "right-hand side" of the email address, 172 called the "domain" in RFC 2822) is appended to the result of step 173 2 to complete the prepared domain name. 175 For example, to request an OPENPGPKEY resource record for a user 176 whose email address is "hugh@example.com", an OPENPGPKEY query would 177 be placed for the following QNAME: "8d5730bd8d76d417bf974c03f59eedb7a 178 f98cb5c3dc73ea8ebbd54b7._openpgpkey.example.com". The corresponding 179 RR in the example.com zone might look like (key shortened for 180 formatting): 182 8d[..]b7._openpgpkey.example.com. IN OPENPGPKEY 184 3.1. Email address variants 186 Some email service providers and email software perform automatic 187 mappings of email addresses based on special characters. This can 188 complicate finding the OPENPGPKEY record associated with the 189 dynamically created email address. Some well known examples are 190 listed below 191 o The LHS is case insensitive, Hugh@example.com and HUGH@example.com 192 map to hugh@example.com. Some email clients also automatically 193 uppercase the first letter of an email address when typing it in. 195 o Everything after a "+" symbol is dynamc. hugh+string@example.com 196 maps to hugh@example.com. 198 o Dots are optional. hugh.daniel@example.com maps to 199 hughdaniel@example.com. 201 Software implementing DNS lookup for the OPENPGPKEY RRtype MAY 202 perform similar translations rules while trying to find the 203 OPENPGPKEY record. 205 4. OpenPGP Key size and DNS 207 Due to the expected size of the OPENPGPKEY record, it is recommended 208 to perform DNS queries for the OPENPGPKEY record using TCP, not UDP. 210 Although the reliability of the transport of large DNS Resource 211 Records has improved in the last years, it is still recommended to 212 keep the DNS records as small as possible without sacrificing the 213 security properties of the public key. The algorithm type and key 214 size of OpenPGP keys should not be modified to accommodate this 215 section. 217 OpenPGP supports various attributes that do not contribute to the 218 security of a key, such as an embedded image file. It is recommended 219 that these properties are not exported to OpenPGP public keyrings 220 that are used to create OPENPGPKEY Resource Records. Some OpenPGP 221 software, for example GnuPG, have support for a "minimal key export" 222 that is well suited to use as OPENPGPKEY RDATA. See Appendix A. 224 5. Security Considerations 226 OPENPGPKEY usage considerations are published in [OPENPGPKEY-USAGE]. 228 5.1. Response size 230 To prevent amplification attacks, an Authoritative DNS server MAY 231 wish to prevent returning OPENPGPKEY records over UDP unless the 232 source IP address has been verified with [DNS-COOKIES]. Such servers 233 MUST NOT return REFUSED, but answer the query with an empty Answer 234 Section and the truncation flag set ("TC=1). 236 5.2. Email address information leak 237 Email addresses are not secret. Using them causes their publication. 238 The hashing of the user name in this document is not a security 239 feature. Publishing OPENPGPKEY records however, will create a list 240 of hashes of valid email addresses, which could simplify obtaining a 241 list of valid email addresses for a particular domain. It is 242 desirable to not ease the harvesting of email addresses where 243 possible. 245 The domain name part of the email address is not used as part of the 246 hash so that hashes can be used in multiple zones deployed using 247 DNAME [RFC6672]. This does makes it slightly easier and cheaper to 248 brute-force the SHA2-224 hashes into common and short user names, as 249 single rainbow tables can be re-used across domains. This can be 250 somewhat countered by using NSEC3. 252 DNS zones that are signed with DNSSEC using NSEC for denial of 253 existence are susceptible to zone-walking, a mechanism that allows 254 someone to enumerate all the OPENPGPKEY hashes in a zone. This can 255 be used in combination with previously hashed common or short user 256 names (in rainbow tables) to deduce valid email addresses. DNSSEC- 257 signed zones using NSEC3 for denial of existence instead of NSEC are 258 significantly harder to brute-force after performing a zone-walk. 260 5.3. Forward security of OpenPGP versus DNSSEC 262 DNSSEC key sizes are chosen based on the fact that these keys can be 263 rolled with next to no requirement for security in the future. If 264 one doubts the strength or security of the DNSSEC key for whatever 265 reason, one simply rolls to a new DNSSEC key with a stronger 266 algorithm or larger key size. On the other hand, OpenPGP key sizes 267 are chosen based on how many years (or decades) their encryption 268 should remain unbreakable by adversaries that own large scale 269 computational resources. 271 This effectively means that anyone who can obtain a DNSSEC private 272 key of a domain name via coercion, theft or brute force calculations, 273 can replace any OPENPGPKEY record in that zone and all of the 274 delegated child zones, irrespective of the key size of the OpenPGP 275 keypair. Any future messages encrypted with the malicious OpenPGP 276 key could then be read. 278 Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only 279 be trusted as much as the DNS domain can be trusted, and is no 280 substitute for in-person key verification of the "Web of Trust". See 281 [OPENPGPKEY-USAGE] for more in-depth information on safe usage of 282 OPENPGPKEY based OpenPGP keys. 284 6. IANA Considerations 286 6.1. OPENPGPKEY RRtype 288 This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has 289 been allocated by IANA from the Resource Record (RR) TYPEs 290 subregistry of the Domain Name System (DNS) Parameters registry. 292 7. Acknowledgements 294 This document is based on RFC-4255 and draft-ietf-dane-smime whose 295 authors are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur 296 Gudmundsson provided feedback and suggested various improvements. 297 Willem Toorop contributed the gpg and hexdump command options. Edwin 298 Taylor contributed language improvements for various iterations of 299 this document. 301 8. References 303 8.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 309 Rose, "DNS Security Introduction and Requirements", RFC 310 4033, March 2005. 312 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 313 Rose, "Resource Records for the DNS Security Extensions", 314 RFC 4034, March 2005. 316 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 317 Rose, "Protocol Modifications for the DNS Security 318 Extensions", RFC 4035, March 2005. 320 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 321 Encodings", RFC 4648, October 2006. 323 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 324 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 326 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 327 Message Syntax", RFC 5754, January 2010. 329 8.2. Informative References 331 [DNS-COOKIES] 332 Eastlake, Donald., "Domain Name System (DNS) Cookies", 333 draft-ietf-dnsop-cookies (work in progress), February 334 2015. 336 [OPENPGPKEY-USAGE] 337 Wouters, P., "Usage considerations with the DNS OPENPGPKEY 338 record", draft-dane-openpgpkey-usage (work in progress), 339 October 2014. 341 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 342 Specification", RFC 2181, July 1997. 344 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 345 2001. 347 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 348 (RR) Types", RFC 3597, September 2003. 350 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 351 Internationalized Email", RFC 6530, February 2012. 353 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 354 DNS", RFC 6672, June 2012. 356 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 357 of Named Entities (DANE) Transport Layer Security (TLS) 358 Protocol: TLSA", RFC 6698, August 2012. 360 Appendix A. Generating OPENPGPKEY records 362 The commonly available GnuPG software can be used to generate the 363 RRdata portion of an OPENPGPKEY record: 365 gpg --export --export-options export-minimal \ 366 hugh@example.com | base64 368 The --armor or -a option of the gpg command should NOT be used, as it 369 adds additional markers around the armored key. 371 When DNS software reading or signing the zone file does not yet 372 support the OPENPGPKEY RRtype, the Generic Record Syntax of [RFC3597] 373 can be used to generate the RDATA. One needs to calculate the number 374 of octets and the actual data in hexadecimal: 376 gpg --export --export-options export-minimal \ 377 hugh@example.com | wc -c 379 gpg --export --export-options export-minimal \ 380 hugh@example.com | hexdump -e \ 381 '"\t" /1 "%.2x"' -e '/32 "\n"' 383 These values can then be used to generate a generic record (line 384 break has been added for formatting): 386 ._openpgpkey.example.com. IN TYPE61 \# \ 387 389 The openpgpkey command in the hash-slinger software can be used to 390 generate complete OPENPGPKEY records 392 ~> openpgpkey --output rfc hugh@example.com 393 8d[...]b7._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...] 395 ~> openpgpkey --output generic hugh@example.com 396 8d[...]b7._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...] 398 Author's Address 400 Paul Wouters 401 Red Hat 403 Email: pwouters@redhat.com