One document matched: draft-ietf-dane-openpgpkey-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY rfc2822 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml">
<!ENTITY rfc3597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml">

<!ENTITY rfc4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">

<!ENTITY rfc4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">

<!ENTITY rfc4880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.xml">

<!ENTITY rfc5233 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5233.xml">

<!ENTITY rfc5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">

<!ENTITY rfc5754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml">

<!ENTITY rfc6530 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6530.xml">
<!ENTITY rfc6672 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6672.xml">
<!ENTITY rfc6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">

<!ENTITY rfc7129 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7129.xml">

<!--ENTITY I-D.draft-shaw-openpgp-hkp-00 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shaw-openpgp-hkp-00.xml"-->

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict='yes'?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc ipr="trust200902"
    docName="draft-ietf-dane-openpgpkey-03"
    category="std"
>

<front>
<title abbrev="DANE for OpenPGP public keys">
Using DANE to Associate OpenPGP public keys with email addresses
</title>

<author initials='P.' surname="Wouters" fullname='Paul Wouters'>
<organization>Red Hat</organization>
<address>
<email>pwouters@redhat.com</email>
</address>
</author>

<date month="April" year="2015"/>

<abstract>
<t>
OpenPGP is a message format for email (and file) encryption that lacks a
standardized lookup mechanism to securely obtain OpenPGP public keys. This
document specifies a method for publishing, locating and verifying OpenPGP
public keys in DNS for a specific email address using a new OPENPGPKEY
DNS Resource Record. Security is provided via DNSSEC.
</t>
</abstract>
</front>

<middle>

<section anchor="introduction" title="Introduction">

<t>
OpenPGP <xref target='RFC4880'/> public keys are used to encrypt or sign
email messages and files. To encrypt an email message, the sender's
email client or MTA needs to know where to find the recipient's OpenPGP
public key. Once obtained, it needs to find some proof that the OpenPGP
public key found actually belongs to the intended recipient.
</t>
<t>
Similarly, when files on a storage media are signed with an OpenPGP
public key that is included on the storage media, this key needs to be
independently verified.
</t>
<t>
Obtaining and verifying an OpenPGP public key is not a straightforward
process as there are no trusted standardized locations for publishing
OpenPGP public keys indexed by email address. Instead, OpenPGP clients
rely on "well-known key servers" that are accessed using the HTTP
Keyserver Protocol ("HKP") or manually by users using a variety of
differently formatted front-end web pages. Worse, some OpenPGP users
announce their OpenPGP public key fingerprint on social media with no
method of validation whatsoever.
</t>
<t>
Currently deployed key servers have no method of validating any uploaded
OpenPGP public key. The key servers simply store and publish. Anyone can
add public keys with any identities and anyone can add signatures to any
other public key using forged malicious identities. Furthermore, once
uploaded, public keys cannot be deleted. People who did not pre-sign a
key revocation can never remove their public key from these key servers
once they lose their private key.
</t>

<t>
The lack of a secure means to look up a public key for an email
address prevents email clients and MUAs from encrypting an outgoing
email to the target recipient, forcing the software to send the message
unencrypted. Currently deployed MTAs only support encrypting the transport
of the email, not the email contents itself, leaving the content of
the email exposed to anyone with access to any of the mail or storage
servers used to transport the email from the sender to the receiver.
</t>
<t>
This document describes a mechanism to associate a user's OpenPGP public
key with their email address, using a new DNS RRtype.
</t>
<t>
The proposed new DNS Resource Record type is secured using DNSSEC. This
trust model is not meant to replace the Trust Signature model. However,
it can be used to encrypt a message that would otherwise have to be sent
out unencrypted, where it could be monitored by a third party in transit
or located in plaintext on a storage or email server. This method can also
be used to obtain the OpenPGP public key which can then be used for
manual verification.
</t>


<section anchor="terminology" title="Terminology">
<t>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 <xref target='RFC2119'/>.</t>

<t>This document also makes use of standard DNSSEC and DANE
terminology. See DNSSEC <xref target='RFC4033'/>, 
<xref target='RFC4034'/>, <xref target='RFC4035'/>, and DANE <xref
target='RFC6698'/> for these terms.</t>
</section>

</section>

<section anchor="openpgpkey_rr" title="The OPENPGPKEY Resource Record">
<t>
The OPENPGPKEY DNS resource record (RR) is used to associate an end entity
OpenPGP public key with an email address, thus forming a "OpenPGP public
key association".
</t>

<t>
The type value allocated for the OPENPGPKEY RR type is 61. The
OPENPGPKEY RR is class independent. The OPENPGPKEY RR has no special
TTL requirements.
</t>

<section anchor="openpgpkey_rrdata" title="The OPENPGPKEY RDATA component">
<t>
The RDATA portion of an OPENPGPKEY Resource Record contains a single
value consisting of a <xref target='RFC4880'/> formatted OpenPGP public
keyring.
</t>
</section>

<section anchor="openpgpkey_wformat" title="The OPENPGPKEY RDATA wire format">
<t>
The RDATA Wire Format consists of a single OpenPGP public key as defined in
Section 5.5.1.1 of <xref target="RFC4880"/>. Note that this format is
without ASCII armor or base64 encoding.
</t>
</section>

<section anchor="openpgpkey_pformat" title="The OPENPGPKEY RDATA presentation format">
<t>
The RDATA Presentation Format, as visible in textual zone files, consists
of a single OpenPGP public key as defined in Section 5.5.1.1. of <xref target='RFC4880'/>
encoded in base64 as defined in Section 4 of <xref target="RFC4648"/>.
</t>
</section>
</section>

<section anchor="openpgpkey_loc" title="Location of the OPENPGPKEY record">
<t>
The DNS does not allow the use of all characters that are supported in the
"local-part" of email addresses as defined in <xref target="RFC2822"/>
and <xref target="RFC6530"/>. Therefore, email addresses are mapped into
DNS using the following method:
<list style="symbols">

<t>
The user name (the "left-hand side" of the email address, called
the "local-part" in the mail message format definition <xref
target="RFC2822"/> and the "local part" in the specification for
internationalized email <xref target="RFC6530"/>) should already be
encoded in UTF-8 (or its subset ASCII). If it is written in another
encoding it should be converted to UTF-8. Next, it is turned into
lowercase and hashed using the SHA2-256 <xref target="RFC5754"/>
algorithm, with the hash truncated to 28 octets and represented in its
hexadecimal representation, to become the left-most label in the prepared
domain name. Truncation comes from the right-most octets. This does not
include the at symbol ("@") that separates the left and right sides of
the email address.
</t>

<t>
The string "_openpgpkey" becomes the second left-most label in the
prepared domain name.
</t>

<t>
The domain name (the "right-hand side" of the email address, called the
"domain" in RFC 2822) is appended to the result of step 2 to complete
the prepared domain name.
</t>
</list></t>

<t>
For example, to request an OPENPGPKEY resource record for a user whose email address
is "hugh@example.com", an OPENPGPKEY query would be placed for the following QNAME:
"c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c1afd6._openpgpkey.example.com".
The corresponding RR in the example.com zone might look like (key shortened for
formatting):

<figure><artwork><![CDATA[
c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>
]]></artwork></figure>
</t>

<section title='Email address variants'>
<t>
Mail systems usually handle variant forms of local-parts. The most
common variants are upper and lower case, which are now invariably
treated as equivalent. But many other variants are possible. Some
systems allow and ignore "noise" characters such as dots, so local
parts johnsmith and John.Smith would be equivalent. Many systems
allow "extensions" such as john-ext or mary+ext where john or mary is
treated as the effective local-part, and the ext is passed to the
recipient for further handling. This can complicate finding the
OPENPGPKEY record associated with the dynamically created email address.
</t>
<t>
<xref target="RFC5321"/> and its predecessors have always made it clear
that only the recipient MTA is allowed to interpret the local-part of
an address. A client supporting OPENPGPKEY therefor MUST NOT perform any
kind of mapping rules based on the email address. As the local-part is
converted to lowercase before hashing, case sensitivity will not cause
problems for the OPENPGPKEY lookup.
</t>
</section>
</section>

<section title='Application use of OPENPGPKEY '>
<t>
The OPENPGPKEY record allows an application or service to obtain or verify
an OpenPGP public key. The lookup result MUST pass DNSSEC validation;
if validation reaches any state other than "Secure", the verification
MUST be treated as a failure.
</t>
<section title='Obtaining an OpenPGP key for a specific email address'>
<t>
If no OpenPGP public keys are known for an email address, an OPENPGPKEY
lookup can be performed to discover the OpenPGP public key that belongs
to a specific email address. This public key can then be used to verify
a received signed message or can be used to send out an encrypted email
message.
</t>
</section>
<section title='Confirming the validity of an OpenPGP key'>
<t>
Locally stored OpenPGP public keys are not automatically refreshed. If the
owner of that key creates a new OpenPGP public key, that owner is unable
to securely notify all users and applications that have its old OpenPGP
public key. Applications and users can perform an OPENPGPKEY lookup to
confirm the locally stored OpenPGP public key is still the correct key
to use. If verifying a locally stored OpenPGP public key and the OpenPGP
public key found through DNS is different from the locally stored OpenPGP
public key, the verification MUST be treated as a failure. An application
that can interact with the user MAY ask the user for guidance.
</t>
</section>
<section title='Verifying an unknown OpenPGP signature'>
<t>
Storage media can be signed using an OpenPGP public key. Even if the
OpenPGP public key is included on the storage media, it needs to be
independently validated. OpenPGP public keys contain one or more IDs
than can have the syntax of an email address. An application can perform
a lookup for an OPENPGPKEY at the expected location for the specific
email address to confirm the validity of the OpenPGP public key. Once
the key has been validated, all files on the storage media that have
been signed by this key can now be verified.
</t>
</section>
</section>

<section title='OpenPGP Key size and DNS'>
<t>
Due to the expected size of the OPENPGPKEY record, it is recommended to
perform DNS queries for the OPENPGPKEY record using TCP, not UDP.
</t>

<t>
Although the reliability of the transport of large DNS Resource Records
has improved in the last years, it is still recommended to keep the 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 accommodate this section.
</t>

<t>
OpenPGP supports various attributes that do not contribute to the
security of a key, such as an embedded image file. It is recommended
that these properties are not exported to OpenPGP public keyrings that
are used to create OPENPGPKEY Resource Records. Some OpenPGP software,
for example GnuPG, have support for a "minimal key export" that is well
suited to use as OPENPGPKEY RDATA. See <xref target='AppendixA'/>.
</t>
</section>

<section anchor="security" title='Security Considerations'>
<t>
OPENPGPKEY usage considerations are published in <xref target="OPENPGPKEY-USAGE"/>.
</t>

<section title='Response size'>
<t>
To prevent amplification attacks, an Authoritative DNS server MAY wish to
prevent returning OPENPGPKEY records over UDP unless the source IP address
has been verified with <xref target="DNS-COOKIES"/>. Such servers MUST
NOT return REFUSED, but answer the query with an empty Answer Section
and the truncation flag set ("TC=1").
</t>
</section>

<section title='Email address information leak'>
<t>
Email addresses are not secret. Using them causes their publication.
The hashing of the user name in this document is not a security feature.
Publishing OPENPGPKEY records however, will create a list of hashes of
valid email addresses, which could simplify obtaining a list of valid
email addresses for a particular domain. It is desirable to not ease
the harvesting of email addresses where possible.
</t>
<t>
The domain name part of the email address is not used as part of the
hash so that hashes can be used in multiple zones deployed using DNAME
<xref target="RFC6672"/>. This does makes it slightly easier and cheaper
to brute-force the SHA2-224 hashes into common and short user names, as
single rainbow tables can be re-used across domains. This can be somewhat
countered by using NSEC3.
</t>
<t>
DNS zones that are signed with DNSSEC using NSEC for denial of existence
are susceptible to zone-walking, a mechanism that allows someone to
enumerate all the OPENPGPKEY hashes in a zone. This can be used in
combination with previously hashed common or short user names (in
rainbow tables) to deduce valid email addresses. DNSSEC-signed zones
using NSEC3 for denial of existence instead of NSEC are significantly
harder to brute-force after performing a zone-walk.
</t>
</section>

<section title='Storage of OPENPGPKEY data'>
<t>
Users may have a local key store with OpenPGP public keys. An application
supporting the use of OPENPGPKEY DNS records MUST NOT modify the local
key store without explicit confirmation of the user, as the application
is unaware of the user's personal policy for adding, removing or updating
their local key store. An application MAY warn the user if an OPENPGPKEY
record does not match the OpenPGP public key in the local key store.
</t>
<t>
OpenPGP public keys obtained via OPENPGPKEY records should not be stored
beyond their DNS TTL value.
</t>
</section>

<section title='Forward security of OpenPGP versus DNSSEC'>
<t>
DNSSEC key sizes are chosen based on the fact that these keys can be
rolled with next to no requirement for security in the future. If one
doubts the strength or security of the DNSSEC key for whatever reason,
one simply rolls to a new DNSSEC key with a stronger algorithm or larger
key size. On the other hand, OpenPGP key sizes are chosen based on how many
years (or decades) their encryption should remain unbreakable by adversaries
that own large scale computational resources.
</t>
<t>
This effectively means that anyone who can obtain a DNSSEC private key of
a domain name via coercion, theft or brute force calculations, can replace
any OPENPGPKEY record in that zone and all of the delegated child zones,
irrespective of the key size of the OpenPGP keypair. Any future messages
encrypted with the malicious OpenPGP key could then be read.
</t>
<t>
Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only
be trusted as much as the DNS domain can be trusted, and is no
substitute for in-person key verification of the "Web of Trust". See
<xref target="OPENPGPKEY-USAGE"/> for more in-depth information on safe
usage of OPENPGPKEY based OpenPGP keys.
</t>
</section>
</section>

<section title='IANA Considerations'>
<section anchor="ianarrtype" title='OPENPGPKEY RRtype'>
<t>
This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has been
allocated by IANA from the Resource Record (RR) TYPEs subregistry of
the Domain Name System (DNS) Parameters registry.
</t>
</section>
</section>


<section title='Acknowledgments'>
<t>
This document is based on RFC-4255 and draft-ietf-dane-smime whose authors
are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur Gudmundsson provided
feedback and suggested various improvements. Willem Toorop contributed the
gpg and hexdump command options. Edwin Taylor contributed language improvements
for various iterations of this document. Text regarding email mappings was
taken from draft-levine-dns-mailbox whose author is John Levine.
</t>
</section>

</middle>

<back>

<references title="Normative References">

&rfc2119;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc4648;
&rfc4880;
&rfc5754;

</references>

<references title="Informative References">

<!-- &I-D.draft-shaw-openpgp-hkp-00; -->
&rfc2181;
&rfc2822;
&rfc3597;
&rfc5233;
&rfc5321;
&rfc6530;
&rfc6672;
&rfc6698;
&rfc7129;

   <reference anchor='OPENPGPKEY-USAGE'>
      <front>
      <title>Usage considerations with the DNS OPENPGPKEY record</title>
      <author initials='P' surname='Wouters' fullname='P. Wouters'>
      <organization>Red Hat</organization>
      </author>
      <date month='October' day='27' year='2014' />
      <abstract><t>
   This document describes usage considerations for OPENPGPKEY DNS records
   for users, email clients, MUA's and MTA's.
       </t></abstract>
      </front>
      <seriesInfo name='Internet-Draft' value='draft-dane-openpgpkey-usage' />
      <format type='TXT' 
            target='http://www.ietf.org/internet-drafts/draft-dane-openpgpkey-usage-01.txt' />
   </reference>

   <reference anchor='DNS-COOKIES'>
      <front>
      <title>Domain Name System (DNS) Cookies</title>
      <author initials='Donald' surname='Eastlake' fullname='Donald Eastlake'>
      <organization>Huawei</organization>
      </author>
      <date month='February' day='22' year='2015' />
      <abstract><t>
       DNS cookies are a lightweight DNS transaction security mechanism that
       provides limited protection to DNS servers and clients against a
       variety of increasingly common denial-of-service and amplification /
       forgery or cache poisoning attacks by off-path attackers. DNS Cookies
       are tolerant of NAT, NAT-PT, and anycast and can be incrementally
       deployed.
       </t></abstract>
      </front>
      <seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-cookies' />
      <format type='TXT' 
            target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-cookies-02.txt' />
   </reference>

</references>

    <section title="Generating OPENPGPKEY records" anchor="AppendixA">
    <t>The commonly available GnuPG software can be used to generate the RRdata portion of
       an OPENPGPKEY record:

<figure><artwork align="left"><![CDATA[

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

]]></artwork></figure>

The --armor or -a option of the gpg command should NOT be used, as it
adds additional markers around the armored key.
</t>

<t>When DNS software reading or signing the zone file does not yet
support the OPENPGPKEY RRtype, the Generic Record Syntax of
<xref target='RFC3597'/> can be used to generate the RDATA. One needs to
calculate the number of octets and the actual data in hexadecimal:

<figure><artwork align="left"><![CDATA[

gpg --export --export-options export-minimal \
    hugh@example.com | wc -c

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

]]></artwork></figure>

These values can then be used to generate a generic record (line break
has been added for formatting):

<figure><artwork align="left"><![CDATA[

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

]]></artwork></figure>

</t>

<t>The openpgpkey command in the hash-slinger software can be used to
generate complete OPENPGPKEY records

<figure><artwork align="left"><![CDATA[

~> 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[...]

]]></artwork></figure>

</t>
</section>


</back>

</rfc>