RFC 7929

DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP

📅 published August 2016, from ietf

DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP 💜

This one is RFC 7929, published by the Internet Engineering Task Force (IETF) in August 2016 🎀. The author is P. Wouters from Red Hat, and the category is Experimental 🧪. The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates.

Abstract 🌸

OpenPGP is the message format people use to encrypt email (and files) 💌, but it doesn't have a standard way to securely look up OpenPGP public keys 😭. DANE is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address, using a brand-new OPENPGPKEY DNS resource record 🦋. Security comes from Secure DNS, but the OPENPGPKEY record is not a replacement for checking authenticity via the "web of trust" or manual verification 🔍. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted 🔐.

Status of This Memo 📜

This document isn't an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧐.

It defines an Experimental Protocol for the Internet community 🧪. It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard; see Section 2 of RFC 7841 📚.

You can find info about this document's current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7929 ✨.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these documents carefully, bestie, because they spell out your rights and restrictions for this document 📑. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️.

Table of Contents 🗺️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Experiment Goal . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  The OPENPGPKEY Resource Record  . . . . . . . . . . . . . . .   5
     2.1.  The OPENPGPKEY RDATA Component  . . . . . . . . . . . . .   6
       2.1.1.  The OPENPGPKEY RDATA Content  . . . . . . . . . . . .   6
       2.1.2.  Reducing the Transferable Public Key Size . . . . . .   7
     2.2.  The OPENPGPKEY RDATA Wire Format  . . . . . . . . . . . .   7
     2.3.  The OPENPGPKEY RDATA Presentation Format  . . . . . . . .   7
   3.  Location of the OPENPGPKEY Record . . . . . . . . . . . . . .   8
   4.  Email Address Variants and Internationalization
       Considerations  . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Application Use of OPENPGPKEY . . . . . . . . . . . . . . . .  10
     5.1.  Obtaining an OpenPGP Key for a Specific Email Address . .  10
     5.2.  Confirming that an OpenPGP Key is Current . . . . . . . .  10
     5.3.  Public Key UIDs and Query Names . . . . . . . . . . . . .  10
   6.  OpenPGP Key Size and DNS  . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.1.  MTA Behavior  . . . . . . . . . . . . . . . . . . . . . .  12
     7.2.  MUA Behavior  . . . . . . . . . . . . . . . . . . . . . .  13
     7.3.  Response Size . . . . . . . . . . . . . . . . . . . . . .  14
     7.4.  Email Address Information Leak  . . . . . . . . . . . . .  14
     7.5.  Storage of OPENPGPKEY Data  . . . . . . . . . . . . . . .  14
     7.6.  Security of OpenPGP versus DNSSEC . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  Generating OPENPGPKEY Records  . . . . . . . . . . .  18
   Appendix B.  OPENPGPKEY IANA Template . . . . . . . . . . . . . .  19
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction ✨

OpenPGP [RFC4880] public keys are what people use to encrypt or sign email messages and files 💌. To encrypt an email message, or verify a sender's OpenPGP signature, the email client (the Mail User Agent, or MUA) or the email server (the Mail Transfer Agent, or MTA) needs to find the recipient's OpenPGP public key 🔍.

OpenPGP clients have relied on centralized "well-known" key servers that are reached with the HTTP Keyserver Protocol [HKP] 🌐. The other option is for users to manually browse a bunch of different front-end websites 🙄. These key servers don't require confirmation of the email address used in the User ID (UID) of an uploaded OpenPGP public key 🚩. Attackers can -- and have -- uploaded rogue public keys with other people's email addresses to these servers 💀.

Once uploaded, public keys can't be deleted 😩. People who didn't pre-sign a key revocation can never remove their OpenPGP public key from these key servers once they've lost their private key. That means they end up receiving encrypted email they can't decrypt 💔.

So these key servers aren't well suited to helping MUAs and MTAs automatically encrypt email, especially when there's no interactive user around 🤖.

This document describes a mechanism for linking a user's OpenPGP public key to their email address, using the OPENPGPKEY DNS RRtype 🎀. These records are published in the DNS zone of the user's email address. If a user loses their private key, the OPENPGPKEY DNS record can simply be updated or removed from the zone 🧹.

The OPENPGPKEY data is secured using Secure DNS [RFC4035] 🔒.

The main goal of the OPENPGPKEY resource record is to stop passive attacks against plaintext emails 🛑. It can also thwart some active attacks (like people uploading rogue keys to key servers in the hopes that others will encrypt to them). Still, this resource record is not a replacement for verifying OpenPGP public keys via "web of trust" signatures, or manually via a fingerprint verification 💅.

1.1. Experiment Goal 🧪

This specification is one experiment in improving access to public keys for end-to-end email security 🔐. There's a range of ways this can reasonably be done for OpenPGP or S/MIME, for example using the DNS, or SMTP, or HTTP. Proposals for each of these have been made, with various levels of support in terms of implementation and deployment. For each such experiment, specifications like this one let experiments be carried out that may succeed, or that may uncover technical or other impediments to large- or small-scale deployments. The IETF encourages people implementing and deploying these experiments to publicly document their experiences, so future specifications in this space can benefit 📝.

This document defines an RRtype whose use is Experimental. The goal of the experiment is to see whether encrypted email usage increases if an automated discovery method is available to MTAs and MUAs, helping end users with email encryption key management 📈.

It's unclear whether this RRtype will scale to some of the larger email service deployments. People have raised concerns about the size of the OPENPGPKEY record and the size of the resulting DNS zone files 😬. This experiment will hopefully give the working group some insight into whether or not that's a problem 🕵️.

If the experiment is successful, the findings are expected to result in an updated document for standards track approval 🏆.

The OPENPGPKEY RRtype somewhat resembles the generic CERT record defined in [RFC4398]. However, the CERT record uses sub-typing with many different types of keys and certificates. It's suspected that its general application to very different protocols (PKIX versus OpenPGP) is the reason for the lack of implementation and deployment 🤷. Furthermore, the CERT record uses sub-typing, which is now considered a bad idea for DNS 🙅.

1.2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🎯.

This document also uses standard DNSSEC and DANE terminology. See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for these terms 🧠.

2. The OPENPGPKEY Resource Record 🍓

The OPENPGPKEY DNS resource record (RR) is used to link an end entity OpenPGP Transferable Public Key (see Section 11.1 of [RFC4880]) to an email address, forming an "OpenPGP public key association" 🔗. Someone who wants more than one OpenPGP key, for example because they're transitioning to a newer, stronger key, can do that by adding multiple OPENPGPKEY records. A single OPENPGPKEY DNS record MUST only contain one OpenPGP key 🔑.

The type value allocated for the OPENPGPKEY RR type is 61. The OPENPGPKEY RR is class independent 🔢.

2.1. The OPENPGPKEY RDATA Component 🎁

The RDATA portion of an OPENPGPKEY resource record contains a single value, which is a Transferable Public Key formatted as specified in [RFC4880] 📦.

2.1.1. The OPENPGPKEY RDATA Content 💎

An OpenPGP Transferable Public Key can be arbitrarily large, but DNS records are limited in size 📏. So when creating OPENPGPKEY DNS records, the OpenPGP Transferable Public Key should be filtered to only contain appropriate and useful data. At a minimum, an OPENPGPKEY Transferable Public Key for the user hugh@example.com should contain:

             o The primary key X
               o One User ID Y, which SHOULD match 'hugh@example.com'
                 o Self-signature from X, binding X to Y

If the primary key is not encryption-capable, at least one relevant subkey should be included, resulting in an OPENPGPKEY Transferable Public Key containing:

           o The primary key X
             o One User ID Y, which SHOULD match 'hugh@example.com'
               o Self-signature from X, binding X to Y
             o Encryption-capable subkey Z
               o Self-signature from X, binding Z to X
             o (Other subkeys, if relevant)

The user can also choose to add a few third-party certifications, which they believe would help with validation in the traditional "web of trust" 🕸️. The resulting OPENPGPKEY Transferable Public Key would then look like this 👑:

           o The primary key X
             o One User ID Y, which SHOULD match 'hugh@example.com'
               o Self-signature from X, binding X to Y
               o Third-party certification from V, binding Y to X
               o (Other third-party certifications, if relevant)
             o Encryption-capable subkey Z
               o Self-signature from X, binding Z to X
             o (Other subkeys, if relevant)

2.1.2. Reducing the Transferable Public Key Size 💅✨

okay bestie, so say you're prepping a Transferable Public Key for one of these OPENPGPKEY RDATA formats and your goal is to make the certificate as small as possible 🫶 you'd usually wanna do a few things:

  • Where one User ID from the certifications matches the looked-up address, strip away the non-matching User IDs and any certifications attached to them (self-signatures or third-party certifications). 🎀
  • Strip away all User Attribute packets and their associated certifications. 🧚
  • Strip away all expired subkeys. 💀 You might wanna keep revoked subkeys if they were revoked before their preferred expiration time, so correspondents actually know about those earlier-than-expected revocations. 👑
  • Strip away all but the most recent self-signature for the remaining User IDs and subkeys. 🍓
  • Optionally strip away any uninteresting or unimportant third-party User ID certifications. This is a value judgment by the user and it's lowkey hard to automate 🙈 At the very least, expired and superseded third-party certifications should be stripped out. 😭 The user should try to keep the most recent and most well-connected certifications in the "web of trust" in their Transferable Public Key. 🌈

2.2. The OPENPGPKEY RDATA Wire Format 🦋

ngl this one is simple: the RDATA Wire Format is a single OpenPGP Transferable Public Key as defined in Section 11.1 of [RFC4880]. No ASCII armor, no base64 encoding, just the raw key 💜

2.3. The OPENPGPKEY RDATA Presentation Format 🌸

The RDATA Presentation Format, the one you see in master files [RFC1035], is a single OpenPGP Transferable Public Key as defined in Section 11.1 of [RFC4880], encoded in base64 as defined in Section 4 of [RFC4648]. It's giving "same key, different outfit" 💅

3. Location of the OPENPGPKEY Record 🗺️

okay so the DNS doesn't allow every character that email addresses support in the "local-part" (the bit before the @) as defined in [RFC5322] and [RFC6530]. 😭 So email addresses get mapped into DNS with the following method:

  1. The "left-hand side" of the email address, called the "local-part" in both the mail message format definition [RFC5322] and the internationalized email spec [RFC6530], gets encoded in UTF-8 (or its ASCII subset). If the local-part is written in another charset, it MUST be converted to UTF-8. 🫧
  2. The local-part gets canonicalized first using these rules. If the local-part is unquoted, any comments and/or folding whitespace (CFWS) around dots (".") gets removed. Any enclosing double quotes get removed. Any literal quoting gets removed too. ✨
  3. If the local-part has any non-ASCII characters, it SHOULD be normalized using Unicode Normalization Form C from [Unicode90]. The recommended normalization rules are in Section 10.1 of [RFC6530]. 🌸
  4. The local-part gets hashed with SHA2-256 [RFC5754], truncated to 28 octets and written in hexadecimal. This becomes the left-most label in the prepared domain name. 🔐
  5. The string "_openpgpkey" becomes the second left-most label. 🎀
  6. The domain (the "right-hand side" of the email address, called the "domain" in [RFC5322]) gets appended to the result of step 4 to finish the prepared domain name. 🦋

For example, if you wanna request an OPENPGPKEY record for a user with the email address "hugh@example.com", you'd place an OPENPGPKEY query for this QNAME:

"c93f1e400f26708f98cb19d936620da35
eec8f72e57f9eec01c1afd6._openpgpkey.example.com"

And the corresponding RR in the example.com zone might look like this (key shortened for formatting 🙈):

c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>

4. Email Address Variants and Internationalization Considerations 🌍

Mail systems usually handle variant forms of local-parts. 🫠 The most common variants are upper- and lowercase, often auto-corrected when a name gets recognized as such. Other variants are systems that ignore "noise" characters like dots, so the local-parts 'johnsmith' and 'John.Smith' would be equivalent. Many systems also allow "extensions" like 'john-ext' or 'mary+ext', where 'john' or 'mary' is treated as the effective local-part and 'ext' gets passed to the recipient for further handling. This can complicate finding the OPENPGPKEY record for the dynamically created email address. 😵‍💫

[RFC5321] and its predecessors have always made it clear that only the recipient MTA is allowed to interpret the local-part of an address. 🛑 So sending MUAs and MTAs that support OPENPGPKEY MUST NOT perform any kind of mapping rules based on the email address. 🙅‍♀️ To improve the chances of finding OPENPGP RRs for a particular local-part, domains that allow variant forms (like treating local-parts as case-insensitive) might publish OPENPGP RRs for all variants of local-parts, might publish variants on first use (for example, a webmail provider that also controls DNS for a domain can publish variants as used by the owner of a particular local-part), or just publish OPENPGP RRs for the most common variants. 🧁

Section 3 above defines how the local-part gets used to figure out where to look for an OPENPGPKEY record. 🔍 Given the variety of local-parts out there, designing a good experiment for this is hard, because: a) some current implementations are known to lowercase at least US-ASCII local-parts, b) we know from (many) other situations that any strategy based on guessing and making multiple DNS queries is not going to achieve consensus for good reasons, and c) the underlying issues are just hard. See Section 10.1 of [RFC6530] for discussion of just some of the issues that would need to be tackled to fully address this problem. 🥲

Still, while this specification is not the place to try to fix these local-part issues, doing so is also not required to determine the outcome of this experiment. 🤷‍♀️ If this experiment succeeds, further work on email addresses with non-ASCII local-parts will be needed. Based on the findings from this experiment, that work would be better than doing nothing, or than starting this experiment on a speculative approach to what is a very complex topic. 🧠

5. Application Use of OPENPGPKEY 🔐

The OPENPGPKEY record lets an application or service get an OpenPGP public key and use it to verify a digital signature or encrypt a message to that public key. 💌 The DNS answer MUST pass DNSSEC validation. If DNSSEC validation reaches any state other than "Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be treated as a failure. 🚫

5.1. Obtaining an OpenPGP Key for a Specific Email Address 📬

If no OpenPGP public keys are known for an email address, an OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key that matches that email address. 🔎 This public key can then be used to verify a received signed message, or to send out an encrypted email message. An application whose attempt fails to retrieve a DNSSEC-verified OPENPGPKEY RR from the DNS should remember that failure for some time, so it doesn't send out a DNS request for every email message it sends. Those DNS requests would constitute a privacy leak. 🕵️‍♀️

5.2. Confirming that an OpenPGP Key is Current ⏰

Locally stored OpenPGP public keys don't get refreshed automatically. 😬 If the owner of a key creates a new OpenPGP public key, that owner can't securely notify every user and application holding the old one. Applications and users can do an OPENPGPKEY lookup to confirm that the locally stored OpenPGP public key is still the correct one to use. If the locally stored key is different from the DNSSEC-validated OpenPGP public key currently published in DNS, the confirmation MUST be treated as a failure, unless the locally stored OpenPGP key signed the newly published OpenPGP public key found in DNS. 💔 An application that can interact with the user MAY ask the user for guidance. Otherwise, the application has to apply local policy. For privacy reasons, an application MUST NOT look up an OpenPGP key from DNSSEC at every use of that key. 🙈

5.3. Public Key UIDs and Query Names 🪪

An OpenPGP public key can be associated with multiple email addresses by specifying multiple key UIDs. ✨ The OpenPGP public key obtained from an OPENPGPKEY RR can be used as long as the query and the resulting data form a proper email to UID identity association. 💖

CNAMEs (see [RFC2181]) and DNAMEs (see [RFC6672]) can be followed to get an OPENPGPKEY RR, as long as the original recipient's email address appears as one of the OpenPGP public key UIDs. For example, say the OPENPGPKEY RR query for hugh@example.com (8d57[...]b7._openpgpkey.example.com) yields a CNAME to 8d57[...]b7._openpgpkey.example.net, and an OPENPGPKEY RR for 8d57[...]b7._openpgpkey.example.net exists. Then this OpenPGP public key can be used, provided one of the key UIDs contains "hugh@example.com". This public key cannot be used if it would only contain the key UID "hugh@example.net". 🔀

If one of the OpenPGP key UIDs contains only a single wildcard as the left-hand side of the email address, such as "@example.com", the OpenPGP public key may be used for any email address within that domain. 🌐 Wildcards in other spots (e.g., "hugh@.com") or regular expressions in key UIDs are not allowed, and any OPENPGPKEY RR containing these MUST be ignored. 🚷

6. OpenPGP Key Size and DNS 📏

Because the OPENPGPKEY record can be pretty big, applications SHOULD use TCP (not UDP) to perform queries for the OPENPGPKEY resource record. 🛜

Although the reliability of large DNS resource record transport has improved over the last few years, it's still recommended to keep DNS records as small as possible without sacrificing the security properties of the public key. 💪 The algorithm type and key size of OpenPGP keys should not be modified to make this section fit. 🙅‍♀️

OpenPGP supports various attributes that don't contribute to a key's security, such as an embedded image file. 🖼️ It's recommended that these properties not be exported to OpenPGP public keyrings that are used to create OPENPGPKEY resource records. Some OpenPGP software (for example, GnuPG) supports a "minimal key export" that's well suited to use as OPENPGPKEY RDATA. See Appendix A. 🎁

7. Security Considerations ✨

Okay bestie, this part is serious, so let's get real 🫶 DNSSEC is not a replacement for the "web of trust" or for checking fingerprints by hand 🔍 DANE for OpenPGP, the way this document describes it, is all about making it easier to grab someone's public key 🔑 Without manually verifying the OpenPGP key you fetched through DANE, you should only use that key for encryption if the only other option is sending the message in plaintext 😬 That does block every passive attack that just captures and logs plaintext email content, but it does nothing against active attacks 💀 A person who publishes an OPENPGPKEY record still expects senders to do their homework with extra, non-DNSSEC checks through other out-of-band methods before they send anything confidential or sensitive 📬

So, to say it plainly: the OPENPGPKEY record MUST NOT be used to send sensitive information without additional verification or confirmation that the OpenPGP key actually belongs to the target recipient 🚫

DNSSEC doesn't protect your queries from Pervasive Monitoring as defined in [RFC7258] 👀 Since most DNS queries are currently unencrypted, a lookup for a target's OPENPGPKEY record could reveal that a user of a monitored recursive DNS server is trying to send encrypted email to someone 😭 MUAs and MTAs usually protect this info by using Transport Layer Security (TLS) encryption through STARTTLS 🔐 The DNS can help with privacy too, but the user has to pick a trusted DNS server that supports these privacy-enhancing features 🌸 Recursive DNS servers can support DNS Query Name Minimalisation [RFC7816], which keeps the QNAME from leaking beyond the recursive DNS server and the nameservers of the actual zone being queried 🧚 Recursive DNS servers can also support TLS [RFC7858] so the path between the end user and the recursive DNS server is encrypted 🦋

Lots of different components could be in charge of encrypting an email to a recipient 💌 It could be the sender's MUA, a MUA plug-in, or the sender's MTA, and each one has its own vibe 🎀 A MUA can ask the user to make a decision before continuing, and it can either accept or refuse a message 🙋‍♀️ The MTA must deliver the message as-is, or encrypt it before delivering 📨 Each of these components should try to encrypt an unencrypted outgoing message whenever it's possible 💖

In theory, two different local-parts could hash to the same value 🤯 This document assumes that a hash collision like that has a negligible chance of happening ✨

Organizations that are required to be able to read everyone's encrypted email should publish the escrow key as the OPENPGPKEY record 🗝️ Mail servers at those organizations MAY optionally re-encrypt the message to the individual's OpenPGP key 🌈

7.1. MTA Behavior

An MTA could be running in stand-alone mode, without access to the sender's OpenPGP public keyring, or it could be set up so it can access the user's OpenPGP public keyring 🗂️ Either way, the MTA MUST NOT modify the user's OpenPGP keyring 🙅‍♀️

An MTA sending an email MUST NOT add the public key it got from an OPENPGPKEY resource record to a permanent public keyring for future use beyond the TTL 🚫💜

If the obtained public key is revoked, the MTA MUST NOT use that key for encryption, even if the result would be sending the message in plaintext 💀

If a message is already encrypted, the MTA SHOULD NOT re-encrypt it, even if different encryption schemes or different encryption keys would be used 🔒

If the DNS request for an OPENPGPKEY record returned an Indeterminate or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the message and queue the plaintext message for encrypted delivery at a later time 😤 If the problem keeps going, the email should be returned through the regular bounce methods 📮

If multiple non-revoked OPENPGPKEY resource records are found, the MTA SHOULD pick the most secure RR based on its local policy 👑

7.2. MUA Behavior

If the public key for a recipient taken from the sender's locally stored public keyring differs from the recipient's OPENPGPKEY RR, the MUA SHOULD halt processing the message and check in with the user to sort out the conflict before going any further 🛑

If the public key for a recipient taken from the sender's locally stored public keyring has properties that contradict the same key from an OPENPGPKEY RR, the MUA SHOULD NOT accept the message for delivery 🙅‍♀️

If multiple non-revoked OPENPGPKEY resource records are found, the MUA SHOULD pick the most secure OpenPGP public key based on its local policy 💅

The MUA MAY interact with the user to resolve any conflicts between locally stored keyrings and OPENPGPKEY RRdata 🙋‍♀️

A MUA that is encrypting a message SHOULD clearly show the user the difference between encrypting to a locally stored, previously user-verified public key and encrypting to a public key from an OPENPGPKEY resource record that the user never verified by hand 👀 This is a big deal, babe 🔥

7.3. Response Size

To stop amplification attacks, an Authoritative DNS server MAY wish to prevent returning OPENPGPKEY records over UDP unless the source IP address has been confirmed with [RFC7873] 🛡️ Servers like that MUST NOT return REFUSED. Instead, they answer the query with an empty answer section and the truncation flag set (TC=1) 🦋

7.4. Email Address Information Leak

Hashing the local-part in this document is not a security feature, so don't get it twisted 🙈 Publishing OPENPGPKEY records creates a list of hashes of valid email addresses, which could make it easier to collect a list of valid email addresses for a particular domain 📋 It's better not to make email harvesting easier wherever possible 🌸

The domain name part of the email address isn't part of the hash, so hashes can be used across multiple zones deployed using DNAME [RFC6672] 🧚 That does make it slightly easier and cheaper to brute-force the SHA2-256 hashes into common and short local-parts, since single rainbow tables can be reused across domains 😩 Using NextSECure version 3 (NSEC3) can help counter this a bit 🛠️

DNS zones signed with DNSSEC that use NSEC for denial of existence are open to zone walking, which lets someone enumerate all the OPENPGPKEY hashes in a zone 🚶‍♀️ Combine that with previously hashed common or short local-parts from rainbow tables, and someone can work out valid email addresses 💀 DNSSEC-signed zones that use NSEC3 for denial of existence instead of NSEC are significantly harder to brute-force after a zone walk 💪

7.5. Storage of OPENPGPKEY Data

Users may have a local key store with OpenPGP public keys 🔐 An application that supports OPENPGPKEY DNS records MUST NOT modify the local key store without the user's explicit confirmation, because the app doesn't know the user's personal policy for adding, removing, or updating their key store 🙅‍♀️ An application MAY warn the user if an OPENPGPKEY record doesn't match the OpenPGP public key in the local key store ⚠️

Applications that can't interact with users, like daemon processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY up to their DNS TTL value ⏳ That way they avoid repeated DNS lookups that third parties could monitor to figure out when an email is being sent to a particular user 👁️

7.6. Security of OpenPGP versus DNSSEC

Anyone who gets a domain's DNSSEC private key through coercion, theft, or brute-force calculations can replace any OPENPGPKEY record in that zone and in all of the delegated child zones 😱 Any future messages encrypted with the malicious OpenPGP key could then be read 💔

So an OpenPGP key obtained from a DNSSEC-validated OPENPGPKEY record can only be trusted as much as the DNS domain can be trusted 🫠 It's no substitute for in-person OpenPGP key verification, or for extra OpenPGP verification through "web of trust" signatures on that OpenPGP key 🤝

8. IANA Considerations 🦋

8.1. OPENPGPKEY RRtype

This document uses a brand-new DNS RR type, OPENPGPKEY 🎉 IANA allocated it the value 61 from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry 💜

The IANA template for OPENPGPKEY is listed in Appendix B 📄 It was submitted to IANA for review on July 23, 2014, and approved on August 12, 2014 ✨

9. References 📚

9.1. Normative References

9.2. Informative References

okay so these are the "good to know" references 📚🎀 they aren't required reading to implement this, but they're the receipts for everything the doc name-drops. bestie, the list is long, so grab a snack 🍓

Appendix A. Generating OPENPGPKEY Records ✨

okay this appendix is the hands-on bit 💅 the commonly available GnuPG software can make a minimum Transferable Public Key for the RRdata part of an OPENPGPKEY record:

gpg --export --export-options export-minimal,no-export-attributes \
    hugh@example.com | base64

heads up: the --armor or -a option of the gpg command should not be used, because it adds extra markers around the armored key 🙈

when your DNS software reading or signing the zone file doesn't support the OPENPGPKEY RRtype yet, the Generic Record Syntax of [RFC3597] can be used to make the RDATA instead. you need to count the octets and dump the actual data in hexadecimal:

gpg --export --export-options export-minimal,no-export-attributes \
    hugh@example.com | wc -c
gpg --export --export-options export-minimal,no-export-attributes \
    hugh@example.com | hexdump -e \
       '"\t" /1 "%.2x"' -e '/32 "\n"'

then you can use those values to build a generic record (a line break has been added for formatting):

<SHA2-256-trunc(hugh)>._openpgpkey.example.com. IN TYPE61 \# \
    <numOctets> <keydata in hex>

and the openpgpkey command in the hash-slinger software can generate complete OPENPGPKEY records for you, which is honestly so convenient 🧚

~> openpgpkey --output rfc hugh@example.com
c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]

~> openpgpkey --output generic hugh@example.com
c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...]

Appendix B. OPENPGPKEY IANA Template 🎀

this is a copy of the original registration template that went to IANA. the text (including the references) hasn't been updated, so it's a little time-capsule 🕰️ it's giving 2014 💀

  A. Submission Date: 23-07-2014

  B.1 Submission Type: [x] New RRTYPE [ ] Modification to RRTYPE
  B.2 Kind of RR: [x] Data RR [ ] Meta-RR

  C. Contact Information for submitter (will be publicly posted):
     Name: Paul Wouters         Email Address: pwouters@redhat.com
     International telephone number: +1-647-896-3464
     Other contact handles: paul@nohats.ca

  D. Motivation for the new RRTYPE application.

     Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC
     protection to faciliate automatic encryption of emails in
     defense against pervasive monitoring.

  E. Description of the proposed RR type.

  http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2

  F. What existing RRTYPE or RRTYPEs come closest to filling that need
     and why are they unsatisfactory?

     The CERT RRtype is the closest match. It unfortunately depends on
     subtyping, and its use in general is no longer recommended. It
     also has no human usable presentation format. Some usage types of
     CERT require external URI's which complicates the security model.
     This was discussed in the dane working group.

  G. What mnemonic is requested for the new RRTYPE (optional)?

     OPENPGPKEY

  H. Does the requested RRTYPE make use of any existing IANA registry
     or require the creation of a new IANA subregistry in DNS
     Parameters? If so, please indicate which registry is to be used
     or created. If a new subregistry is needed, specify the
     allocation policy for it and its initial contents. Also include
     what the modification procedures will be.

     The RDATA part uses the key format specified in RFC-4880, which
     itself use
     https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtm
     This RRcode just uses the formats specified in those registries for
     its RRdata part.

  I. Does the proposal require/expect any changes in DNS
     servers/resolvers that prevent the new type from being processed
     as an unknown RRTYPE (see [RFC3597])?

     No.

  J. Comments:

     Currently, three software implementations of
     draft-ietf-dane-openpgpkey are using a private number.

Acknowledgments 🫶

this doc is built on [RFC4255] and [SMIME], whose authors are Paul Hoffman, Jakob Schlyter, and W. Griffin. Olafur Gudmundsson gave feedback and suggested a bunch of improvements 🙌 Willem Toorop contributed the gpg and hexdump command options. Daniel Kahn Gillmor wrote the text describing the OpenPGP packet formats and filtering options 🔥 Edwin Taylor helped with language improvements across the different versions of this document 💜 and the text about email mappings was taken from [MAILBOX], whose author is John Levine. the real MVPs 👑

Author's Address 💖

Paul Wouters

Red Hat

Email: pwouters@redhat.com

📦 where this page comes from