< draft-ietf-dane-openpgpkey-10.txt		draft-ietf-dane-openpgpkey-11.txt >
	Network Working Group P. Wouters		Network Working Group P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Experimental April 19, 2016		Intended status: Experimental April 29, 2016
	Expires: October 21, 2016		Expires: October 31, 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-10		draft-ietf-dane-openpgpkey-11
	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 October 21, 2016.		This Internet-Draft will expire on October 31, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . 6		2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 7
	3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 6		3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 7
	4. Email address variants and internationalization		4. Email address variants and internationalization
	considerations . . . . . . . . . . . . . . . . . . . . . . . 7		considerations . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 8		5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 8
	5.1. Obtaining an OpenPGP key for a specific email address . . 8		5.1. Obtaining an OpenPGP key for a specific email address . . 9
	5.2. Confirming that an OpenPGP key is current . . . . . . . . 9		5.2. Confirming that an OpenPGP key is current . . . . . . . . 9
	5.3. Public Key UIDs and query names . . . . . . . . . . . . . 9		5.3. Public Key UIDs and query names . . . . . . . . . . . . . 9
	6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 9		6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 11		7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 11		7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 12
	7.3. Response size . . . . . . . . . . . . . . . . . . . . . . 12		7.3. Response size . . . . . . . . . . . . . . . . . . . . . . 12
	7.4. Email address information leak . . . . . . . . . . . . . 12		7.4. Email address information leak . . . . . . . . . . . . . 13
	7.5. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 12		7.5. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 13
	7.6. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 13		7.6. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 13
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
	8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 13		8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 14
	8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 14		8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 15
	8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 15		8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 15		9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 16
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	11.1. Normative References . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . 17
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 18		Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19		Appendix B. OPENPGPKEY IANA template . . . . . . . . . . . . . . 20
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
	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 (MUA) or the email		sender's OpenPGP signature, the email client (MUA) or the email
	server (MTA) needs to locate 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 MUAs and		Therefore, these keyservers are not well suited to support MUAs and
	MTA's to automatically encrypt email - especially in the absence of		MTAs to automatically encrypt email - especially in the absence of an
	an interactive user.		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
	attacks against plaintext emails. While it can also thwart some		attacks against plaintext emails. While it can also thwart some
	active attacks (such as people uploading rogue keys to keyservers in		active attacks (such as people uploading rogue keys to keyservers in
	the hopes that others will encrypt to these rogue keys), this		the hopes that others will encrypt to these rogue keys), this
	resource record is not a replacement for verifying OpenPGP public		resource record is not a replacement for verifying OpenPGP public
	keys via the web of trust signatures, or manually via a fingerprint		keys via the web of trust signatures, or manually via a fingerprint
	verification.		verification.
	1.1. Experiment goal		1.1. Experiment goal
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 13 ¶
	been made with various levels of support in terms of implementation		been made with various levels of support in terms of implementation
	and deployment. For each such experiment, specifications such as		and deployment. For each such experiment, specifications such as
	this will enable experiments to be carried out that may succeed or		this will enable experiments to be carried out that may succeed or
	that may uncover technical or other impediments to large- or small-		that may uncover technical or other impediments to large- or small-
	scale deployments. The IETF encourages those implementing and		scale deployments. The IETF encourages those implementing and
	deploying such experiments to publicly document their experiences so		deploying such experiments to publicly document their experiences so
	that future specifications in this space can benefit.		that future specifications in this space can benefit.
	This document defines an RRtype whose use is Experimental. The goal		This document defines an RRtype whose use is Experimental. The goal
	of the experiment is to see whether encrypted email usage will		of the experiment is to see whether encrypted email usage will
	increase if an automated discovery method is available to MTA's and		increase if an automated discovery method is available to MTAs and
	MUA's to help the enduser with email encryption key management.		MUAs to help the enduser with email encryption key management.
	It is unclear if this RRtype will scale to some of the larger email		It is unclear if this RRtype will scale to some of the larger email
	service deployments. Concerns have been raised about the size of the		service deployments. Concerns have been raised about the size of the
	OPENPGPKEY record and the size of the resulting DNS zone files. This		OPENPGPKEY record and the size of the resulting DNS zone files. This
	experiment hopefully will give the working group some insight into		experiment hopefully will give the working group some insight into
	whether this is a problem or not.		whether this is a problem or not.
	If the experiment is successful, it is expected that the findings of		If the experiment is successful, it is expected that the findings of
	the experiment will result in an updated document for standards track		the experiment will result in an updated document for standards track
	approval.		approval.
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 32 ¶
	An OpenPGP Transferable Public Key can be arbitrarily large. DNS		An OpenPGP Transferable Public Key can be arbitrarily large. DNS
	records are limited in size. When creating OPENPGPKEY DNS records,		records are limited in size. When creating OPENPGPKEY DNS records,
	the OpenPGP Transferable Public Key should be filtered to only		the OpenPGP Transferable Public Key should be filtered to only
	contain appropriate and useful data. At a minimum, an OPENPGPKEY		contain appropriate and useful data. At a minimum, an OPENPGPKEY
	Transferable Public Key for the user hugh@example.com should contain:		Transferable Public Key for the user hugh@example.com should contain:
	o The primary key X		o The primary key X
	o One User ID Y, which SHOULD match 'hugh@example.com'		o One User ID Y, which SHOULD match 'hugh@example.com'
	o self-signature from X, binding X to Y		o self-signature from X, binding X to Y
	If the primary key is not encryption-capable, a relevant subkey		If the primary key is not encryption-capable, at least one relevant
	should be included resulting in an OPENPGPKEY Transferable Public Key		subkey should be included resulting in an OPENPGPKEY Transferable
	containing:		Public Key containing:
	o The primary key X		o The primary key X
	o One User ID Y, which SHOULD match 'hugh@example.com'		o One User ID Y, which SHOULD match 'hugh@example.com'
	o self-signature from X, binding X to Y		o self-signature from X, binding X to Y
	o encryption-capable subkey Z		o encryption-capable subkey Z
	o self-signature from X, binding Z to X		o self-signature from X, binding Z to X
	o [ other subkeys if relevant ... ]		o [ other subkeys if relevant ... ]
	The user can also elect to add a few third-party certifications which		The user can also elect to add a few third-party certifications which
	they believe would be helpful for validation in the traditional Web		they believe would be helpful for validation in the traditional Web
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 22 ¶
	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. MUA's and MTA's supporting OPENPGPKEY therefore MUST NOT		address. Therefor, sending MUAs and MTAs supporting OPENPGPKEY MUST
	perform any kind of mapping rules based on the email address.		NOT 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 8, line 33 ¶		skipping to change at page 9, line 4 ¶
	However, while this specification is not the place to try to address		However, while this specification is not the place to try to address
	these issues with local-parts, doing so is also not required to		these issues with local-parts, doing so is also not required to
	determine the outcome of this experiment. If this experiment		determine the outcome of this experiment. If this experiment
	succeeds then further work on email addresses with non-ASCII local-		succeeds then further work on email addresses with non-ASCII local-
	parts will be needed and that would be better based on the findings		parts will be needed and that would be better based on the findings
	from this experiment, rather than doing nothing or starting this		from this experiment, rather than doing nothing or starting this
	experiment based on a speculative approach to what is a very complex		experiment based on a speculative approach to what is a very complex
	topic.		topic.
	5. Application use of OPENPGPKEY		5. Application use of OPENPGPKEY
	The OPENPGPKEY record allows an application or service to obtain an		The OPENPGPKEY record allows an application or service to obtain an
	OpenPGP public key and use it for verifying a digital signature or		OpenPGP public key and use it for verifying a digital signature or
	encrypting a message to the public key. The DNS answer MUST pass		encrypting a message to the public key. The DNS answer MUST pass
	DNSSEC validation; if DNSSEC validation reaches any state other than		DNSSEC validation; if DNSSEC validation reaches any state other than
	"Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be		"Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be
	treated as a failure.		treated as a failure.
	5.1. Obtaining an OpenPGP key for a specific email address		5.1. Obtaining an OpenPGP key for a specific email address
	If no OpenPGP public keys are known for an email address, an		If no OpenPGP public keys are known for an email address, an
	OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key		OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
	that corresponds to that email address. This public key can then be		that corresponds to that email address. This public key can then be
	used to verify a received signed message or can be used to send out		used to verify a received signed message or can be used to send out
	an encrypted email message. An application whose attempt fails to		an encrypted email message. An application whose attempt fails to
	retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember		retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
	that failure for some time to avoid sending out a DNS request for		that failure for some time to avoid sending out a DNS request for
	each email message the application is sending out; such DNS requests		each email message the application is sending out; such DNS requests
	constitute a privacy leak		constitute a privacy leak.
	5.2. Confirming that an OpenPGP key is current		5.2. Confirming that an OpenPGP key is current
	Locally stored OpenPGP public keys are not automatically refreshed.		Locally stored OpenPGP public keys are not automatically refreshed.
	If the owner of that key creates a new OpenPGP public key, that owner		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		is unable to securely notify all users and applications that have its
	old OpenPGP public key. Applications and users can perform an		old OpenPGP public key. Applications and users can perform an
	OPENPGPKEY lookup to confirm the locally stored OpenPGP public key is		OPENPGPKEY lookup to confirm the locally stored OpenPGP public key is
	still the correct key to use. If the locally stored OpenPGP public		still the correct key to use. If the locally stored OpenPGP public
	key is different from the DNSSEC validated OpenPGP public key		key is different from the DNSSEC validated OpenPGP public key
	skipping to change at page 10, line 38 ¶		skipping to change at page 11, line 9 ¶
	plaintext email content, it is not a security measure against active		plaintext email content, it is not a security measure against active
	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.
			DNSSEC does not protect the queries from Pervasive Monitoring as
			defined in [RFC7258]. Since DNS queries are currently mostly
			unencrypted, a query to lookup a target OPENPGPKEY record could
			reveal that a user using the (monitored) recursive DNS server is
			attempting to send encrypted email to a target. This information is
			normally protected by the MUAs and MTAs by using TLS encryption using
			STARTTLS. The DNS itself can mitigate some privacy concerns, but the
			user needs to select a trusted DNS server that supports these privay
			enhancing feaures. Recursive DNS servers can support DNS Query Name
			Minimalisation [RFC7816] which limits leaking the QNAME to only the
			recursive DNS server and the the nameservers of the actual zone being
			queried for. Recursive DNS servers can also support TLS
			[DNS-OVER-TLS] to ensure the path between the enduser and the
			recursive DNS server is encrypted.
	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 MUA		message to a target recipient. It could be done by the sender's MUA
	or a MUA plugin or the sender's MTA. Each of these have their own		or a MUA plugin or the sender's MTA. Each of these have their own
	characteristics. A MUA can ask the user to make a decision before		characteristics. A MUA can ask the user to make a decision before
	continuing. The MUA can either accept or refuse a message. The MTA		continuing. The MUA can either accept or refuse a message. The MTA
	must deliver the message as-is, or encrypt the message before		must deliver the message as-is, or encrypt the message before
	delivering. Each of these components should attempt to encrypt an		delivering. Each of these components should attempt to encrypt an
	unencrypted outgoing message whenever possible.		unencrypted outgoing 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.
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 43 ¶
	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.
	The MUA MAY interact with the user to resolve any conflicts between		The MUA MAY interact with the user to resolve any conflicts between
	locally stored keyrings and OPENPGPKEY RRdata.		locally stored keyrings and OPENPGPKEY RRdata.
	A MUA that is encrypting a message SHOULD clearly indicate to the		A MUA that is encrypting a message SHOULD clearly indicate to the
	user the difference between encrypting to a locally stored and		user the difference between encrypting to a locally stored and
	previously user-verified public key and encrypting to public key		previously user-verified public key and encrypting to a public key
	obtained via an OPENPGPKEY resource record that was not manually		obtained via an OPENPGPKEY resource record that was not manually
	verified by the user in the past.		verified by the user in the past.
	7.3. 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.4. Email address information leak		7.4. Email address information leak
	The hashing of the local-part 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 will create a list of hashes
	of hashes of valid email addresses, which could simplify obtaining a		of valid email addresses, which could simplify obtaining a list of
	list of valid email addresses for a particular domain. It is		valid email addresses for a particular domain. It is desirable to
	desirable to not ease the harvesting of email addresses where		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 local-parts, as		brute-force the SHA2-256 hashes into common and short local-parts, as
	single rainbow tables can be re-used across domains. This can be		single rainbow tables can be re-used across domains. This can be
	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
	skipping to change at page 15, line 50 ¶		skipping to change at page 16, line 40 ¶
	Interoperability: No report.		Interoperability: No report.
	9. IANA Considerations		9. IANA Considerations
	9.1. OPENPGPKEY RRtype		9.1. OPENPGPKEY RRtype
	This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has		This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has
	been allocated by IANA from the Resource Record (RR) TYPEs		been allocated by IANA from the Resource Record (RR) TYPEs
	subregistry of the Domain Name System (DNS) Parameters registry.		subregistry of the Domain Name System (DNS) Parameters registry.
			The IANA template for OPENPGPKEY is listed in Appendix B. It was
			submitted to IANA on July 23, 2014, reference number #773394 and
			approved on August 12, 2014.
	10. Acknowledgments		10. Acknowledgments
	This document is based on RFC-4255 and draft-ietf-dane-smime whose
			This document is based on [RFC4255] and [draft-ietf-dane-smime] whose
	authors are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur		authors are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur
	Gudmundsson provided feedback and suggested various improvements.		Gudmundsson provided feedback and suggested various improvements.
	Willem Toorop contributed the gpg and hexdump command options.		Willem Toorop contributed the gpg and hexdump command options.
	Daniel Kahn Gillmor provided the text describing the OpenPGP packet		Daniel Kahn Gillmor provided the text describing the OpenPGP packet
	formats and filtering options. Edwin Taylor contributed language		formats and filtering options. Edwin Taylor contributed language
	improvements for various iterations of this document. Text regarding		improvements for various iterations of this document. Text regarding
	email mappings was taken from draft-levine-dns-mailbox whose author		email mappings was taken from [draft-levine-dns-mailbox] whose author
	is John Levine.		is John Levine.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <http://www.rfc-editor.org/info/rfc1035>.
	skipping to change at page 17, line 13 ¶		skipping to change at page 18, line 7 ¶
	Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/		Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/
	RFC4880, November 2007,		RFC4880, November 2007,
	<http://www.rfc-editor.org/info/rfc4880>.		<http://www.rfc-editor.org/info/rfc4880>.
	[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic		[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
	Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January		Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
	2010, <http://www.rfc-editor.org/info/rfc5754>.		2010, <http://www.rfc-editor.org/info/rfc5754>.
	11.2. Informative References		11.2. Informative References
			[DNS-OVER-TLS]
			Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
			and P. Hoffman, "Specification for DNS over TLS", draft-
			ietf-dprive-dns-over-tls (work in progress), March 2016.
	[EDNS-COOKIE]		[EDNS-COOKIE]
	Eastlake, Donald., "Domain Name System (DNS) Cookies",		Eastlake, Donald., "Domain Name System (DNS) Cookies",
	draft-ietf-dnsop-cookies (work in progress), August 2015.		draft-ietf-dnsop-cookies (work in progress), August 2015.
	[HKP] Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)",		[HKP] Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)",
	draft-shaw-openpgp-hkp (work in progress), March 2013.		draft-shaw-openpgp-hkp (work in progress), March 2013.
	[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record		[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
	(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September		(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
	2003, <http://www.rfc-editor.org/info/rfc3597>.		2003, <http://www.rfc-editor.org/info/rfc3597>.
			[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
			Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
			DOI 10.17487/RFC4255, January 2006,
			<http://www.rfc-editor.org/info/rfc4255>.
	[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name		[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
	System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,		System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,
	<http://www.rfc-editor.org/info/rfc4398>.		<http://www.rfc-editor.org/info/rfc4398>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<http://www.rfc-editor.org/info/rfc5321>.		<http://www.rfc-editor.org/info/rfc5321>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
	10.17487/RFC5322, October 2008,		10.17487/RFC5322, October 2008,
	skipping to change at page 18, line 10 ¶		skipping to change at page 19, line 10 ¶
	[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication		[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
	of Named Entities (DANE) Transport Layer Security (TLS)		of Named Entities (DANE) Transport Layer Security (TLS)
	Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August		Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
	2012, <http://www.rfc-editor.org/info/rfc6698>.		2012, <http://www.rfc-editor.org/info/rfc6698>.
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", RFC 6982, DOI		Code: The Implementation Status Section", RFC 6982, DOI
	10.17487/RFC6982, July 2013,		10.17487/RFC6982, July 2013,
	<http://www.rfc-editor.org/info/rfc6982>.		<http://www.rfc-editor.org/info/rfc6982>.
			[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
			Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
			2014, <http://www.rfc-editor.org/info/rfc7258>.
			[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
			Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
			<http://www.rfc-editor.org/info/rfc7816>.
	[Unicode52]		[Unicode52]
	The Unicode Consortium, "The Unicode Standard, Version		The Unicode Consortium, "The Unicode Standard, Version
	5.2.0, defined by: "The Unicode Standard, Version 5.2.0",		5.2.0, defined by: "The Unicode Standard, Version 5.2.0",
	(Mountain View, CA: The Unicode Consortium, 2009. ISBN		(Mountain View, CA: The Unicode Consortium, 2009. ISBN
	978-1-936213-00-9).", October 2009.		978-1-936213-00-9).", October 2009.
			[draft-ietf-dane-smime]
			Hoffman, P. and J. Schlyter, "Using Secure DNS to
			Associate Certificates with Domain Names For S/MIME",
			draft-ietf-dane-smime (work in progress), February 2016.
			[draft-levine-dns-mailbox]
			Levine, J., "Encoding mailbox local-parts in the DNS",
			draft-ietf-dane-smime (work in progress), September 2015.
	Appendix A. Generating OPENPGPKEY records		Appendix A. Generating OPENPGPKEY records
	The commonly available GnuPG software can be used to generate a		The commonly available GnuPG software can be used to generate a
	minimum Transferable Public Key for the RRdata portion of an		minimum Transferable Public Key for the RRdata portion of an
	OPENPGPKEY record:		OPENPGPKEY record:
	gpg --export --export-options export-minimal,no-export-attributes \		gpg --export --export-options export-minimal,no-export-attributes \
	hugh@example.com | base64		hugh@example.com | base64
	The --armor or -a option of the gpg command should NOT be used, as it		The --armor or -a option of the gpg command should NOT be used, as it
	skipping to change at page 19, line 17 ¶		skipping to change at page 20, line 27 ¶
	The openpgpkey command in the hash-slinger software can be used to		The openpgpkey command in the hash-slinger software can be used to
	generate complete OPENPGPKEY records		generate complete OPENPGPKEY records
	~> openpgpkey --output rfc hugh@example.com		~> openpgpkey --output rfc hugh@example.com
	c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]		c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]
	~> openpgpkey --output generic hugh@example.com		~> openpgpkey --output generic hugh@example.com
	c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...]		c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...]
			Appendix B. OPENPGPKEY IANA template
			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 uses
			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.
	Author's Address		Author's Address
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
End of changes. 32 change blocks.
	45 lines changed or deleted		151 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/