< draft-ietf-dane-openpgpkey-08.txt   draft-ietf-dane-openpgpkey-09.txt >
Network Working Group P. Wouters Network Working Group P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Experimental March 08, 2016 Intended status: Experimental April 13, 2016
Expires: September 09, 2016 Expires: October 15, 2016
Using DANE to Associate OpenPGP public keys with email addresses Using DANE to Associate OpenPGP public keys with email addresses
draft-ietf-dane-openpgpkey-08 draft-ietf-dane-openpgpkey-09
Abstract Abstract
OpenPGP is a message format for email (and file) encryption that OpenPGP is a message format for email (and file) encryption that
lacks a standardized lookup mechanism to securely obtain OpenPGP lacks a standardized lookup mechanism to securely obtain OpenPGP
public keys. DNS-Based Authentication of Named Entities ("DANE") is public keys. DNS-Based Authentication of Named Entities ("DANE") is
a method for publishing public keys in DNS. This document specifies a method for publishing public keys in DNS. This document specifies
a DANE method for publishing and locating OpenPGP public keys in DNS a DANE method for publishing and locating OpenPGP public keys in DNS
for a specific email address using a new OPENPGPKEY DNS Resource for a specific email address using a new OPENPGPKEY DNS Resource
Record. Security is provided via Secure DNS, however the OPENPGPKEY Record. Security is provided via Secure DNS, however the OPENPGPKEY
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 09, 2016. This Internet-Draft will expire on October 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Experiment goal . . . . . . . . . . . . . . . . . . . . . 3 1.1. Experiment goal . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 4 2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 4
2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 5 2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 5
2.1.1. The OPENPGPKEY RDATA content . . . . . . . . . . . . 5 2.1.1. The OPENPGPKEY RDATA content . . . . . . . . . . . . 5
2.1.2. Reducing the Transferable Public Key size . . . . . . 6 2.1.2. Reducing the Transferable Public Key size . . . . . . 6
2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 6 2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 6
2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 7 2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 6
3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 7 3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 6
4. Email address variants and internationalization 4. Email address variants and internationalization
considerations . . . . . . . . . . . . . . . . . . . . . . . 8 considerations . . . . . . . . . . . . . . . . . . . . . . . 7
5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 8 5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 8
5.1. Obtaining an OpenPGP key for a specific email address . . 9 5.1. Obtaining an OpenPGP key for a specific email address . . 8
5.2. Confirming that an OpenPGP key is current . . . . . . . . 9 5.2. Confirming that an OpenPGP key is current . . . . . . . . 8
5.3. Public Key UIDs and query names . . . . . . . . . . . . . 9 5.3. Public Key UIDs and query names . . . . . . . . . . . . . 9
6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 10 6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 11 7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 10
7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 11 7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Email client behaviour . . . . . . . . . . . . . . . . . 12 7.3. Response size . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Response size . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Email address information leak . . . . . . . . . . . . . 12
7.5. Email address information leak . . . . . . . . . . . . . 12 7.5. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 12
7.6. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 13 7.6. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 13
7.7. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 13
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 14 8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 13
8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 14 8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 14
8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 15 8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 16 9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 18 Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
OpenPGP [RFC4880] public keys are used to encrypt or sign email OpenPGP [RFC4880] public keys are used to encrypt or sign email
messages and files. To encrypt an email message, or verify a messages and files. To encrypt an email message, or verify a
sender's OpenPGP signature, the email client or MTA needs to locate sender's OpenPGP signature, the email client (MUA) or the email
the recipient's OpenPGP public key. server (MTA) needs to locate the recipient's OpenPGP public key.
OpenPGP clients have relied on centralized "well-known" key servers OpenPGP clients have relied on centralized "well-known" key servers
that are accessed using the HTTP Keyserver Protocol [HKP]. that are accessed using the HTTP Keyserver Protocol [HKP].
Alternatively, users need to manually browse a variety of different Alternatively, users need to manually browse a variety of different
front-end websites. These key servers do not require a confirmation front-end websites. These key servers do not require a confirmation
of the email address used in the User ID of the uploaded OpenPGP of the email address used in the User ID of the uploaded OpenPGP
public key. Attackers can - and have - uploaded rogue public keys public key. Attackers can - and have - uploaded rogue public keys
with other people's email addresses to these key servers. with other people's email addresses to these key servers.
Once uploaded, public keys cannot be deleted. People who did not Once uploaded, public keys cannot be deleted. People who did not
pre-sign a key revocation can never remove their OpenPGP public key pre-sign a key revocation can never remove their OpenPGP public key
from these key servers once they have lost access to their private from these key servers once they have lost access to their private
key. This results in receiving encrypted email that cannot be key. This results in receiving encrypted email that cannot be
decrypted. decrypted.
Therefore, these keyservers are not well suited to support email Therefore, these keyservers are not well suited to support MUAs and
clients and MTA's to automatically encrypt email - especially in the MTA's to automatically encrypt email - especially in the absence of
absence of an interactive user. an interactive user.
This document describes a mechanism to associate a user's OpenPGP This document describes a mechanism to associate a user's OpenPGP
public key with their email address, using the OPENPGPKEY DNS RRtype. public key with their email address, using the OPENPGPKEY DNS RRtype.
These records are published in the DNS zone of the user's email These records are published in the DNS zone of the user's email
address. If the user loses their private key, the OPENPGPKEY DNS address. If the user loses their private key, the OPENPGPKEY DNS
record can simply be updated or removed from the zone. record can simply be updated or removed from the zone.
The OPENPGPKEY data is secured using Secure DNS [RFC4035] The OPENPGPKEY data is secured using Secure DNS [RFC4035]
The main goal of the OPENPGPKEY resource record is to stop passive The main goal of the OPENPGPKEY resource record is to stop passive
skipping to change at page 8, line 20 skipping to change at page 7, line 48
systems that ignore "noise" characters such as dots, so that local systems that ignore "noise" characters such as dots, so that local
parts johnsmith and John.Smith would be equivalent. Many systems parts johnsmith and John.Smith would be equivalent. Many systems
allow "extensions" such as john-ext or mary+ext where john or mary is 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 treated as the effective local-part, and the ext is passed to the
recipient for further handling. This can complicate finding the recipient for further handling. This can complicate finding the
OPENPGPKEY record associated with the dynamically created email OPENPGPKEY record associated with the dynamically created email
address. address.
[RFC5321] and its predecessors have always made it clear that only [RFC5321] and its predecessors have always made it clear that only
the recipient MTA is allowed to interpret the local-part of an the recipient MTA is allowed to interpret the local-part of an
address. A client supporting OPENPGPKEY therefore MUST NOT perform address. MUA's and MTA's supporting OPENPGPKEY therefore MUST NOT
any kind of mapping rules based on the email address. perform any kind of mapping rules based on the email address.
Section 3 above defines how the local-part is used to determine the Section 3 above defines how the local-part is used to determine the
location in which one looks for an OPENPGPKEY record. Given the location in which one looks for an OPENPGPKEY record. Given the
variety of local-parts seen in email, designing a good experiment for variety of local-parts seen in email, designing a good experiment for
this is difficult as: a) some current implementations are known to this is difficult as: a) some current implementations are known to
lowercase at least US-ASCII local-parts, b) we know from (many) other lowercase at least US-ASCII local-parts, b) we know from (many) other
situations that any strategy based on guessing and making multiple situations that any strategy based on guessing and making multiple
DNS queries is not going to achieve consensus for good reasons, and DNS queries is not going to achieve consensus for good reasons, and
c) the underlying issues are just hard - see Section 10.1 of c) the underlying issues are just hard - see Section 10.1 of
[RFC6530] for discussion of just some of the issues that would need [RFC6530] for discussion of just some of the issues that would need
skipping to change at page 10, line 52 skipping to change at page 10, line 32
attacks. A user who publishes an OPENPGPKEY record in DNS still attacks. A user who publishes an OPENPGPKEY record in DNS still
expects senders to perform their due diligence by additional (non- expects senders to perform their due diligence by additional (non-
DNSSEC) verification of their public key via other out-of-band DNSSEC) verification of their public key via other out-of-band
methods before sending any confidential or sensitive information. methods before sending any confidential or sensitive information.
In other words, the OPENPGPKEY record MUST NOT be used to send In other words, the OPENPGPKEY record MUST NOT be used to send
sensitive information without additional verification or confirmation sensitive information without additional verification or confirmation
that the OpenPGP key actually belongs to the target recipient. that the OpenPGP key actually belongs to the target recipient.
Various components could be responsible for encrypting an email Various components could be responsible for encrypting an email
message to a target recipient. It could be done by the sender's message to a target recipient. It could be done by the sender's MUA
email client or software plugin, the sender's Mail User Agent (MUA) or a MUA plugin or the sender's MTA. Each of these have their own
or the sender's Mail Transfer Agent (MTA). Each of these have their characteristics. A MUA can ask the user to make a decision before
own characteristics. An email client can ask the user to make a continuing. The MUA can either accept or refuse a message. The MTA
decision before continuing. The MUA can either accept or refuse a must deliver the message as-is, or encrypt the message before
message. The MTA must deliver the message as-is, or encrypt the delivering. Each of these components should attempt to encrypt an
message before delivering. Each of these programs should attempt to unencrypted outgoing message whenever possible.
encrypt an unencrypted received message whenever possible.
In theory, two different local-parts could hash to the same value. In theory, two different local-parts could hash to the same value.
This document assumes that such a hash collision has a negliable This document assumes that such a hash collision has a negliable
chance of happening. chance of happening.
Organisations that are required to be able to read everyone's Organisations that are required to be able to read everyone's
encrypted email should publish the escrow key as the OPENPGPKEY encrypted email should publish the escrow key as the OPENPGPKEY
record. Mail servers of such organizations MAY optionally re-encrypt record. Mail servers of such organizations MAY optionally re-encrypt
the message to the individual's OpenPGP key. the message to the individual's OpenPGP key.
skipping to change at page 12, line 4 skipping to change at page 11, line 29
If the DNS request for an OPENPGPKEY record returned an Indeterminate If the DNS request for an OPENPGPKEY record returned an Indeterminate
or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the
message and queue the plaintext message for encrypted delivery at a message and queue the plaintext message for encrypted delivery at a
later time. If the problem persists, the email should be returned later time. If the problem persists, the email should be returned
via the regular bounce methods. via the regular bounce methods.
If multiple non-revoked OPENPGPKEY resource records are found, the If multiple non-revoked OPENPGPKEY resource records are found, the
MTA SHOULD pick the most secure RR based on its local policy. MTA SHOULD pick the most secure RR based on its local policy.
7.2. MUA behaviour 7.2. MUA behaviour
If the public key for a recipient obtained from the locally stored If the public key for a recipient obtained from the locally stored
sender's public keyring differs from the recipient's OPENPGPKEY RR, sender's public keyring differs from the recipient's OPENPGPKEY RR,
the MUA MUST NOT accept the message for delivery. the MUA SHOULD halt processing the message and interact with the user
to resolve the conflict before continuing to process the message.
If the public key for a recipient obtained from the locally stored If the public key for a recipient obtained from the locally stored
sender's public keyring contains contradicting properties for the sender's public keyring contains contradicting properties for the
same key obtained from an OPENPGPKEY RR, the MUA SHOULD NOT accept same key obtained from an OPENPGPKEY RR, the MUA SHOULD NOT accept
the message for delivery. the message for delivery.
If multiple non-revoked OPENPGPKEY resource records are found, the If multiple non-revoked OPENPGPKEY resource records are found, the
MUA SHOULD pick the most secure OpenPGP public key based on its local MUA SHOULD pick the most secure OpenPGP public key based on its local
policy. policy.
7.3. Email client behaviour The MUA MAY interact with the user to resolve any conflicts between
locally stored keyrings and OPENPGPKEY RRdata.
Email clients should adhere to the above listed MUA behaviour.
Additionally, an email client MAY interact with the user to resolve
any conflicts between locally stored keyrings and OPENPGPKEY RRdata.
An email client that is encrypting a message SHOULD clearly indicate A MUA that is encrypting a message SHOULD clearly indicate to the
to the user the difference between encrypting to a locally stored and user the difference between encrypting to a locally stored and
user verified public key and encrypting to an unverified public key previously user-verified public key and encrypting to public key
obtained via an OPENPGPKEY resource record. obtained via an OPENPGPKEY resource record that was not manually
verified by the user in the past.
7.4. Response size 7.3. Response size
To prevent amplification attacks, an Authoritative DNS server MAY To prevent amplification attacks, an Authoritative DNS server MAY
wish to prevent returning OPENPGPKEY records over UDP unless the wish to prevent returning OPENPGPKEY records over UDP unless the
source IP address has been confirmed with [EDNS-COOKIE]. Such source IP address has been confirmed with [EDNS-COOKIE]. Such
servers MUST NOT return REFUSED, but answer the query with an empty servers MUST NOT return REFUSED, but answer the query with an empty
Answer Section and the truncation flag set ("TC=1"). Answer Section and the truncation flag set ("TC=1").
7.5. Email address information leak 7.4. Email address information leak
The hashing of the user name in this document is not a security The hashing of the local-part in this document is not a security
feature. Publishing OPENPGPKEY records however, will create a list feature. Publishing OPENPGPKEY records however, will create a list
of hashes of valid email addresses, which could simplify obtaining a of hashes of valid email addresses, which could simplify obtaining a
list of valid email addresses for a particular domain. It is list of valid email addresses for a particular domain. It is
desirable to not ease the harvesting of email addresses where desirable to not ease the harvesting of email addresses where
possible. possible.
The domain name part of the email address is not used as part of the 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 hash so that hashes can be used in multiple zones deployed using
DNAME [RFC6672]. This does makes it slightly easier and cheaper to DNAME [RFC6672]. This does makes it slightly easier and cheaper to
brute-force the SHA2-256 hashes into common and short user names, as brute-force the SHA2-256 hashes into common and short user names, as
skipping to change at page 13, line 13 skipping to change at page 12, line 37
somewhat countered by using NSEC3. somewhat countered by using NSEC3.
DNS zones that are signed with DNSSEC using NSEC for denial of DNS zones that are signed with DNSSEC using NSEC for denial of
existence are susceptible to zone-walking, a mechanism that allows existence are susceptible to zone-walking, a mechanism that allows
someone to enumerate all the OPENPGPKEY hashes in a zone. This can someone to enumerate all the OPENPGPKEY hashes in a zone. This can
be used in combination with previously hashed common or short user be used in combination with previously hashed common or short user
names (in rainbow tables) to deduce valid email addresses. DNSSEC- names (in rainbow tables) to deduce valid email addresses. DNSSEC-
signed zones using NSEC3 for denial of existence instead of NSEC are signed zones using NSEC3 for denial of existence instead of NSEC are
significantly harder to brute-force after performing a zone-walk. significantly harder to brute-force after performing a zone-walk.
7.6. Storage of OPENPGPKEY data 7.5. Storage of OPENPGPKEY data
Users may have a local key store with OpenPGP public keys. An Users may have a local key store with OpenPGP public keys. An
application supporting the use of OPENPGPKEY DNS records MUST NOT application supporting the use of OPENPGPKEY DNS records MUST NOT
modify the local key store without explicit confirmation of the user, modify the local key store without explicit confirmation of the user,
as the application is unaware of the user's personal policy for as the application is unaware of the user's personal policy for
adding, removing or updating their local key store. An application adding, removing or updating their local key store. An application
MAY warn the user if an OPENPGPKEY record does not match the OpenPGP MAY warn the user if an OPENPGPKEY record does not match the OpenPGP
public key in the local key store. public key in the local key store.
Applications that cannot interact with users, such as daemon Applications that cannot interact with users, such as daemon
processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY
up to their DNS TTL value. This avoids repeated DNS lookups that up to their DNS TTL value. This avoids repeated DNS lookups that
third parties could monitor to determine when an email is being sent third parties could monitor to determine when an email is being sent
to a particular user. to a particular user.
7.7. Security of OpenPGP versus DNSSEC 7.6. Security of OpenPGP versus DNSSEC
Anyone who can obtain a DNSSEC private key of a domain name via Anyone who can obtain a DNSSEC private key of a domain name via
coercion, theft or brute force calculations, can replace any coercion, theft or brute force calculations, can replace any
OPENPGPKEY record in that zone and all of the delegated child zones. OPENPGPKEY record in that zone and all of the delegated child zones.
Any future messages encrypted with the malicious OpenPGP key could Any future messages encrypted with the malicious OpenPGP key could
then be read. then be read.
Therefore, an OpenPGP key obtained via a DNSSEC validated OPENPGPKEY Therefore, an OpenPGP key obtained via a DNSSEC validated OPENPGPKEY
record can only be trusted as much as the DNS domain can be trusted, record can only be trusted as much as the DNS domain can be trusted,
and is no substitute for in-person OpenPGP key verification or and is no substitute for in-person OpenPGP key verification or
 End of changes. 27 change blocks. 
55 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/