idnits 2.17.1 draft-ietf-dane-openpgpkey-06.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 (October 20, 2015) is 3109 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) 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. Wouters 3 Internet-Draft Red Hat 4 Intended status: Experimental October 20, 2015 5 Expires: April 22, 2016 7 Using DANE to Associate OpenPGP public keys with email addresses 8 draft-ietf-dane-openpgpkey-06 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 and 15 locating OpenPGP public keys in DNS for a specific email address 16 using a new OPENPGPKEY DNS Resource Record. Security is provided via 17 Secure DNS, however the OPENPGPKEY record is not a replacement for 18 verification of authenticity via the "Web of Trust" or manual 19 verification. The OPENPGPKEY record can be used to encrypt an email 20 that would otherwise have to be send unencrypted. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 22, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Experiment goal . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 4 60 2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 4 61 2.1.1. The OPENPGPKEY RDATA content . . . . . . . . . . . . 5 62 2.1.2. Reducing the Transferable Public Key size . . . . . . 5 63 2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 6 64 2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 6 65 3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 6 66 4. Email address variants . . . . . . . . . . . . . . . . . . . 7 67 5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 7 68 5.1. Obtaining an OpenPGP key for a specific email address . . 8 69 5.2. Confirming the validity of an OpenPGP key . . . . . . . . 8 70 5.3. Public Key UIDs and query names . . . . . . . . . . . . . 8 71 6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 10 74 7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 11 75 7.3. Email client behaviour . . . . . . . . . . . . . . . . . 11 76 7.4. Response size . . . . . . . . . . . . . . . . . . . . . . 11 77 7.5. Email address information leak . . . . . . . . . . . . . 11 78 7.6. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 12 79 7.7. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 12 80 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 81 8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 13 82 8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 14 83 8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 14 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 15 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 11.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 17 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 OpenPGP [RFC4880] public keys are used to encrypt or sign email 96 messages and files. To encrypt an email message, or verify a 97 sender's OpenPGP signature, the email client or MTA needs to locate 98 the recipient's OpenPGP public key. 100 OpenPGP clients have relied on centralized "well-known" key servers 101 that are accessed using either the HTTP Keyserver Protocol [HKP] 102 Alternatively, users need to manually browse a variety of different 103 front-end websites. These key servers do not validate the email 104 address in the User ID of the uploaded OpenPGP public key. Attackers 105 can - and have - uploaded rogue public keys with other people's email 106 addresses to these key servers. 108 Once uploaded, public keys cannot be deleted. People who did not 109 pre-sign a key revocation can never remove their OpenPGP public key 110 from these key servers once they have lost access to their private 111 key. This results in receiving encrypted email that cannot be 112 decrypted. 114 Therefor, these keyservers are not well suited to support email 115 clients and MTA's to automatically encrypt email - especially in the 116 absence of an interactive user. 118 This document describes a mechanism to associate a user's OpenPGP 119 public key with their email address, using the OPENPGPKEY DNS RRtype. 120 These records are published in the DNS zone of the user's email 121 address. If the user loses their private key, the OPENPGPKEY DNS 122 record can simply be updated or removed from the zone. 124 The OPENPGPKEY data is secured using Secure DNS. 126 The main goal of the OPENPGPKEY resource record is to stop passive 127 attacks against plaintext emails. While it can also twart some 128 active attacks (such as people uploading rogue keys to keyservers in 129 the hopes that others will encrypt to these rogue keys), this 130 resource record is not a replacement for verifying OpenPGP public 131 keys via the web of trust signatures, or manually via a fingerprint 132 verification. 134 1.1. Experiment goal 136 This document defines an Experimental RRtype. The goal of the 137 experiment is to see whether encrypted email usage will increase if 138 an automated discovery method is available to MTA's and MUA's to help 139 the enduser with email encryption key management. 141 It is unclear if this RRtype will scale to some of the larger email 142 service deployments. Concerns have been raised about the size of the 143 OPENPGPKEY record and the size of the resulting DNS zone files. This 144 experiment hopefully will give the working group some insight into 145 whether this is a problem or not. 147 If the experiment is successful, it is expected that the findings of 148 the experiment will result in an updated document for standards track 149 approval. 151 The OPENPGPKEY RRtype somewhat resembles the generic CERT record 152 defined in [RFC4398]. However, the CERT record uses sub-typing with 153 many different types of keys and certificates. It is suspected that 154 its generality of very different protocols (PKIX versus OpenPGP) has 155 been the cause for lack of implementation and deployment. 156 Furthermore, the CERT record uses sub-typing, which is now considered 157 to be a bad idea for DNS. 159 1.2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 This document also makes use of standard DNSSEC and DANE terminology. 166 See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for 167 these terms. 169 2. The OPENPGPKEY Resource Record 171 The OPENPGPKEY DNS resource record (RR) is used to associate an end 172 entity OpenPGP Transferable Public Key (see Section 11.1 of [RFC4880] 173 with an email address, thus forming a "OpenPGP public key 174 association". A user that wishes to specify more than one OpenPGP 175 key, for example because they are transitioning to a newer stronger 176 key, can do so by adding multiple OPENPGPKEY records. A single 177 OPENPGPKEY DNS record MUST only contain one OpenPGP key. 179 The type value allocated for the OPENPGPKEY RR type is 61. The 180 OPENPGPKEY RR is class independent. The OPENPGPKEY RR has no special 181 TTL requirements. 183 2.1. The OPENPGPKEY RDATA component 185 The RDATA portion of an OPENPGPKEY Resource Record contains a single 186 value consisting of a [RFC4880] formatted Transferable Public Key. 188 2.1.1. The OPENPGPKEY RDATA content 190 An OpenPGP Transferable Public Key can be arbitrarily large. DNS 191 records are limited in size. When creating OPENPGPKEY DNS records, 192 the OpenPGP Transferable Public Key should be filtered to only 193 contain appropriate and useful data. At a minimum, an OPENPGPKEY 194 Transferable Public Key for the user hugh@example.com should contain: 196 o The primary key X 197 o One User ID Y, which SHOULD match 'hugh@example.com' 198 o self-signature from X, binding X to Y 200 If the primary key is not encryption-capable, a relevant subkey 201 should be included resulting in an OPENPGPKEY Transferable Public Key 202 containing: 204 o The primary key X 205 o One User ID Y, which SHOULD match 'hugh@example.com' 206 o self-signature from X, binding X to Y 207 o encryption-capable subkey Z 208 o self-signature from X, binding Z to X 209 o [ other subkeys if relevant ... ] 211 The user can also elect to add a few third-party certifications which 212 they believe would be helpful for validation in the traditional Web 213 Of Trust. The resulting OPENPGPKEY Transferable Public Key would 214 then look like: 216 o The primary key X 217 o One User ID Y, which SHOULD match 'hugh@example.com' 218 o self-signature from X, binding X to Y 219 o third-party certification from V, binding Y to X 220 o [ other third-party certifications if relevant ... ] 221 o encryption-capable subkey Z 222 o self-signature from X, binding Z to X 223 o [ other subkeys if relevant ... ] 225 2.1.2. Reducing the Transferable Public Key size 227 When preparing a Transferable Public Key for a specific OPENPGPKEY 228 RDATA format with the goal of minimizing certificate size, a user 229 would typically want to: 231 o Where one User ID from the certifications matches the looked-up 232 address, strip away non-matching User IDs and any associated 233 certifications (self-signatures or third-party certifications) 235 o Strip away all User Attribute packets and associated 236 certifications. 238 o Strip away all expired subkeys. The user may want to keep revoked 239 subkeys if these were revoked prior to their preferred expiration 240 time to ensure that correspondents know about these earlier then 241 expected revocations. 243 o Strip away all but the most recent self-sig for the remaining user 244 IDs and subkeys 246 o Optionally strip away any uninteresting or unimportant third-party 247 User ID certifications. This is a value judgment by the user that 248 is difficult to automate. At the very least, expired and 249 superseded third-party certifcations should be stripped out. The 250 user should attempt to keep the most recent and most well 251 connected certifications in the Web Of Trust in their Transferable 252 Public Key. 254 2.2. The OPENPGPKEY RDATA wire format 256 The RDATA Wire Format consists of a single OpenPGP Transferable 257 Public Key as defined in Section 11.1 of [RFC4880]. Note that this 258 format is without ASCII armor or base64 encoding. 260 2.3. The OPENPGPKEY RDATA presentation format 262 The RDATA Presentation Format, as visible in textual zone files, 263 consists of a single OpenPGP Transferable Public Key as defined in 264 Section 11.1 of [RFC4880] encoded in base64 as defined in Section 4 265 of [RFC4648]. 267 3. Location of the OPENPGPKEY record 269 The DNS does not allow the use of all characters that are supported 270 in the "local-part" of email addresses as defined in [RFC5322] and 271 [RFC6530]. Therefore, email addresses are mapped into DNS using the 272 following method: 274 o The user name (the "left-hand side" of the email address, called 275 the "local-part" in the mail message format definition [RFC5322] 276 and the local-part in the specification for internationalized 277 email [RFC6530]) should already be encoded in UTF-8 (or its subset 278 ASCII). If it is written in another encoding it should be 279 converted to UTF-8 and then hashed using the SHA2-256 [RFC5754] 280 algorithm, with the hash truncated to 28 octets and represented in 281 its hexadecimal representation, to become the left-most label in 282 the prepared domain name. Truncation comes from the right-most 283 octets. This does not include the at symbol ("@") that separates 284 the left and right sides of the email address. 286 o The string "_openpgpkey" becomes the second left-most label in the 287 prepared domain name. 289 o The domain name (the "right-hand side" of the email address, 290 called the "domain" in RFC 5322) is appended to the result of step 291 2 to complete the prepared domain name. 293 For example, to request an OPENPGPKEY resource record for a user 294 whose email address is "hugh@example.com", an OPENPGPKEY query would 295 be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35 296 eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The corresponding 297 RR in the example.com zone might look like (key shortened for 298 formatting): 300 c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY 302 4. Email address variants 304 Mail systems usually handle variant forms of local-parts. The most 305 common variants are upper and lower case, often automatically 306 corrected when a name is recognized as such. Other variants include 307 systems that ignore "noise" characters such as dots, so that local 308 parts johnsmith and John.Smith would be equivalent. Many systems 309 allow "extensions" such as john-ext or mary+ext where john or mary is 310 treated as the effective local-part, and the ext is passed to the 311 recipient for further handling. This can complicate finding the 312 OPENPGPKEY record associated with the dynamically created email 313 address. 315 [RFC5321] and its predecessors have always made it clear that only 316 the recipient MTA is allowed to interpret the local-part of an 317 address. A client supporting OPENPGPKEY therefor MUST NOT perform 318 any kind of mapping rules based on the email address. 320 5. Application use of OPENPGPKEY 322 The OPENPGPKEY record allows an application or service to obtain or 323 verify an OpenPGP public key. The lookup result MUST pass DNSSEC 324 validation; if validation reaches any state other than "Secure", the 325 verification MUST be treated as a failure. 327 5.1. Obtaining an OpenPGP key for a specific email address 329 If no OpenPGP public keys are known for an email address, an 330 OPENPGPKEY lookup MAY be performed to discover the OpenPGP public key 331 that belongs to a specific email address. This public key can then 332 be used to verify a received signed message or can be used to send 333 out an encrypted email message. An application that confirms the 334 lack of an OPENPGPKEY record SHOULD remember this for some time to 335 avoid sending out a DNS request for each email message that is sent 336 out as this constitutes a privacy leak. 338 5.2. Confirming the validity of an OpenPGP key 340 Locally stored OpenPGP public keys are not automatically refreshed. 341 If the owner of that key creates a new OpenPGP public key, that owner 342 is unable to securely notify all users and applications that have its 343 old OpenPGP public key. Applications and users can perform an 344 OPENPGPKEY lookup to confirm the locally stored OpenPGP public key is 345 still the correct key to use. If verifying a locally stored OpenPGP 346 public key and the OpenPGP public key found through DNS is different 347 from the locally stored OpenPGP public key, the verification MUST be 348 treated as a failure. An application that can interact with the user 349 MAY ask the user for guidance. For privacy reasons, an application 350 MUST NOT attempt to validate a locally stored OpenPGP key using an 351 OPENPGPKEY lookup at every use of that key. 353 5.3. Public Key UIDs and query names 355 An OpenPGP public key can be associated with multiple email addresses 356 by specifying multiple key uids. The OpenPGP public key obtained 357 from a OPENPGPKEY RR can be used as long as the query and resulting 358 data form a proper email to uid identity association. 360 CNAME's (see [RFC2181]) and DNAME's (see [RFC6672]) can be followed 361 to obtain an OPENPGPKEY RR, as long as the original recipient's email 362 address appears as one of the OpenPGP public key uids. For example, 363 if the OPENPGPKEY RR query for hugh@example.com 364 (8d57[...]b7._openpgpkey.example.com) yields a CNAME to 365 8d57[...]b7._openpgpkey.example.net, and an OPENPGPKEY RR for 366 8d57[...]b7._openpgpkey.example.net exists, then this OpenPGP public 367 key can be used, provided one of the key uids contains 368 "hugh@example.com". This public key cannot be used if it would only 369 contain the key uid "hugh@example.net". 371 If one of the OpenPGP key uids contains only a single wildcard as the 372 LHS of the email address, such as "*@example.com", the OpenPGP public 373 key may be used for any email address within that domain. Wildcards 374 at other locations (eg hugh@*.com) or regular expressions in key uids 375 are not allowed, and any OPENPGPKEY RR containing these should be 376 ignored. 378 6. OpenPGP Key size and DNS 380 Due to the expected size of the OPENPGPKEY record, applications 381 SHOULD use TCP - not UDP - to perform queries for the OPENPGPKEY 382 Resource Record. 384 Although the reliability of the transport of large DNS Resource 385 Records has improved in the last years, it is still recommended to 386 keep the DNS records as small as possible without sacrificing the 387 security properties of the public key. The algorithm type and key 388 size of OpenPGP keys should not be modified to accommodate this 389 section. 391 OpenPGP supports various attributes that do not contribute to the 392 security of a key, such as an embedded image file. It is recommended 393 that these properties are not exported to OpenPGP public keyrings 394 that are used to create OPENPGPKEY Resource Records. Some OpenPGP 395 software, for example GnuPG, have support for a "minimal key export" 396 that is well suited to use as OPENPGPKEY RDATA. See Appendix A. 398 7. Security Considerations 400 DNSSEC is not an alternative for the "web of trust" or for manual 401 fingerprint verification by humans. It is a solution aimed to ease 402 obtaining someone's public key, and without manual verification 403 should be treated as "better then plaintext" only. While this twarts 404 all passive attacks that simply capture and log all plaintext email 405 content, it is not a security measure against active attacks. A user 406 who publishes an OPENPGPKEY record in DNS still expects senders to 407 perform their due diligence by additional verification of their 408 public key via other out-of-band methods before sending any 409 confidential or sensitive information. 411 In other words, the OPENPGPKEY record MUST NOT be used to send 412 sensitive information without additional verification or confirmation 413 that the OpenPGP key actually belongs to the target recipient. 415 Various components could be responsible for encrypting an email 416 message to a target recipient. It could be done by the sender's 417 email client or software plugin, the sender's Mail User Agent (MUA) 418 or the sender's Mail Transfer Agent (MTA). Each of these have their 419 own characteristics. An email client can direct the human to make a 420 decision before continuing. The MUA can either accept or refuse a 421 message. The MTA must deliver the message as-is, or encrypt the 422 message before delivering. Each of these programs should attempt to 423 encrypt an unencrypted received message whenever possible. 425 Organisations that are required to be able to read everyone's 426 encrypted email should publish the escrow key as the OPENPGPKEY 427 record. Upon receipt, such mail servers MAY optionally re-encrypt 428 the message to the individual's OpenPGP key. 430 7.1. MTA behaviour 432 An MTA could be operating in a stand-alone mode, without access to 433 the sender's OpenPGP public keyring, or in a way where it can access 434 the user's OpenPGP public keyring. Regardless, the MTA MUST NOT 435 modify the user's OpenPGP keyring. 437 An MTA sending an email MUST NOT add the public key obtained from an 438 OPENPGPKEY resource record to a permanent public keyring for future 439 use beyond the TTL. 441 If the obtained public key is revoked, the MTA MUST NOT use the key 442 for encryption, even if that would result in sending the message in 443 plaintext. 445 If a message is already encrypted, the MTA SHOULD NOT re-encrypt the 446 message, even if different encryption schemes or different encryption 447 keys would be used. 449 If the DNS request for an OPENPGPKEY record returned an 450 "indeterminate" or "bogus" answer, the MTA MUST NOT sent the message 451 and queue the plaintext message for encrypted delivery at a later 452 time. If the problem persists, the email should be returned via the 453 regular bounce methods. 455 If multiple non-revoked OPENPGPKEY resource records are found, the 456 MTA SHOULD pick the most secure RR based on its local policy. 458 7.2. MUA behaviour 460 If the public key for a recipient obtained from the locally stored 461 sender's public keyring differs from the recipient's OPENPGPKEY RR, 462 the MUA MUST NOT accept the message for delivery. 464 If the public key for a recipient obtained from the locally stored 465 sender's public keyring contains contradicting properties for the 466 same key obtained from an OPENPGPKEY RR, the MUA SHOULD NOT accept 467 the message for delivery. 469 If multiple non-revoked OPENPGPKEY resource records are found, the 470 MUA SHOULD pick the most secure OpenPGP public key based on its local 471 policy. 473 7.3. Email client behaviour 475 Email clients should adhere to the above listed MUA behaviour. 476 Additionally, an email client MAY interact with the user to resolve 477 any conflicts between locally stored keyrings and OPENPGPKEY RRdata. 479 An email client that is encrypting a message SHOULD clearly indicate 480 to the user the difference between encrypting to a locally stored and 481 humanly verified public key and encrypting to an unverified (by the 482 human sender) public key obtained via an OPENPGPKEY resource record. 484 7.4. Response size 486 To prevent amplification attacks, an Authoritative DNS server MAY 487 wish to prevent returning OPENPGPKEY records over UDP unless the 488 source IP address has been verified with [EDNS-COOKIE]. Such servers 489 MUST NOT return REFUSED, but answer the query with an empty Answer 490 Section and the truncation flag set ("TC=1"). 492 7.5. Email address information leak 494 The hashing of the user name in this document is not a security 495 feature. Publishing OPENPGPKEY records however, will create a list 496 of hashes of valid email addresses, which could simplify obtaining a 497 list of valid email addresses for a particular domain. It is 498 desirable to not ease the harvesting of email addresses where 499 possible. 501 The domain name part of the email address is not used as part of the 502 hash so that hashes can be used in multiple zones deployed using 503 DNAME [RFC6672]. This does makes it slightly easier and cheaper to 504 brute-force the SHA2-256 hashes into common and short user names, as 505 single rainbow tables can be re-used across domains. This can be 506 somewhat countered by using NSEC3. 508 DNS zones that are signed with DNSSEC using NSEC for denial of 509 existence are susceptible to zone-walking, a mechanism that allows 510 someone to enumerate all the OPENPGPKEY hashes in a zone. This can 511 be used in combination with previously hashed common or short user 512 names (in rainbow tables) to deduce valid email addresses. DNSSEC- 513 signed zones using NSEC3 for denial of existence instead of NSEC are 514 significantly harder to brute-force after performing a zone-walk. 516 7.6. Storage of OPENPGPKEY data 518 Users may have a local key store with OpenPGP public keys. An 519 application supporting the use of OPENPGPKEY DNS records MUST NOT 520 modify the local key store without explicit confirmation of the user, 521 as the application is unaware of the user's personal policy for 522 adding, removing or updating their local key store. An application 523 MAY warn the user if an OPENPGPKEY record does not match the OpenPGP 524 public key in the local key store. 526 Applications that cannot interact with users, such as daemon 527 processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY 528 up to their DNS TTL value. This avoids repeated DNS lookups that 529 third parties could monitor to determine when an email is being sent 530 to a particular user. 532 7.7. Security of OpenPGP versus DNSSEC 534 Anyone who can obtain a DNSSEC private key of a domain name via 535 coercion, theft or brute force calculations, can replace any 536 OPENPGPKEY record in that zone and all of the delegated child zones. 537 Any future messages encrypted with the malicious OpenPGP key could 538 then be read. 540 Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only 541 be trusted as much as the DNS domain can be trusted, and is no 542 substitute for in-person key verification or verification via the 543 "Web of Trust". 545 8. Implementation Status 547 [RFC Editor Note: Please remove this entire seciton prior to 548 publication as an RFC.] 549 This section records the status of known implementations of the 550 protocol defined by this specification at the time of posting of this 551 Internet-Draft, and is based on a proposal described in [RFC6982]. 552 The description of implementations in this section is intended to 553 assist the IETF in its decision processes in progressing drafts to 554 RFCs. Please note that the listing of any individual implementation 555 here does not imply endorsement by the IETF. Furthermore, no effort 556 has been spent to verify the information presented here that was 557 supplied by IETF contributors. This is not intended as, and must not 558 be construed to be, a catalog of available implementations or their 559 features. Readers are advised to note that other implementations may 560 exist. According to RFC 6982, "this will allow reviewers and working 561 groups to assign due consideration to documents that have the benefit 562 of running code, which may serve as evidence of valuable 563 experimentation and feedback that have made the implemented protocols 564 more mature. It is up to the individual working groups to use this 565 information as they see fit." 567 8.1. The GNU Privacy Guard (GNUpg) 569 Implementation Name and Details: The GNUpg software, more commonly 570 known as "gpg", is is available at https://gnupg.org/ 572 Brief Description: Support has been added to gnupg in their git 573 repository. This code is expected to be part of the next official 574 release. 576 Level of Maturity: The implementation has just been added and has 577 not seen widespread deployment. 579 Coverage: The implementation follows the latest draft with the 580 exception that it first performs a lowercase of the local-part 581 before hashing. This is done because other parts in the code that 582 perform a lookup of uid already performed a localcasing to ensure 583 case insensitivity. The implementors are tracking the development 584 of this draft in particular with respect to the lowercase issue. 586 Licensing: All code is covered under the GNU Public License version 587 3 or later. 589 Implementation Experience: Currrent experience limited to small test 590 networks only 592 Contact Information: https://gnupg.org/ 594 Interoperability: No report. 596 8.2. hash-slinger 598 Implementation Name and Details: The hash-slinger software is a 599 collection of tools to generate and verify application DNS records 600 written by the author of this document. It is available at http:/ 601 /people.redhat.com/pwouters/ 603 Brief Description: Support has been added in the form of an 604 "openpgpkey" command that can generate, fetch and verify 605 OPENPGPKEY records. 607 Level of Maturity: The implementation has been around for a few 608 months but has not seen widespread deployment. 610 Coverage: The implementation follows the latest draft with the 611 exception that it first performs a lowercase of the local-part 612 before hashing. 614 Licensing: All code is covered under the GNU Public License version 615 3 or later. 617 Implementation Experience: Currrent experience limited to small test 618 networks only 620 Contact Information: pwouters@redhat.com 622 Interoperability: No report. 624 8.3. openpgpkey-milter 626 Implementation Name and Details: The openpgpkey-milter is a Postfix 627 and Sendmail Mail server plugin (milter) that automatically 628 encrypts email before sending further to other SMTP servers. It 629 is written by the author of this document. It is available at 630 http://github.com/letoams/openpgpkey-milter/ 632 Brief Description: Before forwarding an unencrypted email, the 633 plugin looks for the presence of an OPENPGPKEY record. When 634 available, it will encrypt the email message and send out the 635 encrypted email. 637 Level of Maturity: The implementation has been around for a few 638 months but has not seen widespread deployment. 640 Coverage: The implementation follows the latest draft with the 641 exception that it first performs a lowercase of the local-part 642 before hashing. 644 Licensing: All code is covered under the GNU Public License version 645 3 or later. 647 Implementation Experience: Currrent experience limited to small test 648 networks only 650 Contact Information: pwouters@redhat.com 652 Interoperability: No report. 654 9. IANA Considerations 656 9.1. OPENPGPKEY RRtype 658 This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has 659 been allocated by IANA from the Resource Record (RR) TYPEs 660 subregistry of the Domain Name System (DNS) Parameters registry. 662 10. Acknowledgments 664 This document is based on RFC-4255 and draft-ietf-dane-smime whose 665 authors are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur 666 Gudmundsson provided feedback and suggested various improvements. 667 Willem Toorop contributed the gpg and hexdump command options. 668 Daniel Kahn Gillmor provided the text describing the OpenPGP packet 669 formats and filtering options. Edwin Taylor contributed language 670 improvements for various iterations of this document. Text regarding 671 email mappings was taken from draft-levine-dns-mailbox whose author 672 is John Levine. 674 11. References 676 11.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 680 RFC2119, March 1997, 681 . 683 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 684 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 685 . 687 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 688 Rose, "DNS Security Introduction and Requirements", RFC 689 4033, DOI 10.17487/RFC4033, March 2005, 690 . 692 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 693 Rose, "Resource Records for the DNS Security Extensions", 694 RFC 4034, DOI 10.17487/RFC4034, March 2005, 695 . 697 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 698 Rose, "Protocol Modifications for the DNS Security 699 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 700 . 702 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 703 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 704 . 706 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 707 Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/ 708 RFC4880, November 2007, 709 . 711 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 712 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 713 2010, . 715 11.2. Informative References 717 [EDNS-COOKIE] 718 Eastlake, Donald., "Domain Name System (DNS) Cookies", 719 draft-ietf-dnsop-cookies (work in progress), August 2015. 721 [HKP] Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", 722 draft-shaw-openpgp-hkp (work in progress), March 2013. 724 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 725 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 726 2003, . 728 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 729 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 730 . 732 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 733 DOI 10.17487/RFC5321, October 2008, 734 . 736 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 737 10.17487/RFC5322, October 2008, 738 . 740 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 741 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 742 February 2012, . 744 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 745 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 746 . 748 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 749 of Named Entities (DANE) Transport Layer Security (TLS) 750 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 751 2012, . 753 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 754 Code: The Implementation Status Section", RFC 6982, DOI 755 10.17487/RFC6982, July 2013, 756 . 758 Appendix A. Generating OPENPGPKEY records 760 The commonly available GnuPG software can be used to generate a 761 minimum Transferable Public Key for the RRdata portion of an 762 OPENPGPKEY record: 764 gpg --export --export-options export-minimal,no-export-attributes \ 765 hugh@example.com | base64 767 The --armor or -a option of the gpg command should NOT be used, as it 768 adds additional markers around the armored key. 770 When DNS software reading or signing the zone file does not yet 771 support the OPENPGPKEY RRtype, the Generic Record Syntax of [RFC3597] 772 can be used to generate the RDATA. One needs to calculate the number 773 of octets and the actual data in hexadecimal: 775 gpg --export --export-options export-minimal,no-export-attributes \ 776 hugh@example.com | wc -c 778 gpg --export --export-options export-minimal,no-export-attributes \ 779 hugh@example.com | hexdump -e \ 780 '"\t" /1 "%.2x"' -e '/32 "\n"' 782 These values can then be used to generate a generic record (line 783 break has been added for formatting): 785 ._openpgpkey.example.com. IN TYPE61 \# \ 786 788 The openpgpkey command in the hash-slinger software can be used to 789 generate complete OPENPGPKEY records 791 ~> openpgpkey --output rfc hugh@example.com 792 c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...] 794 ~> openpgpkey --output generic hugh@example.com 795 c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...] 797 Author's Address 799 Paul Wouters 800 Red Hat 802 Email: pwouters@redhat.com