< draft-ietf-dnsop-edns-key-tag-03.txt		draft-ietf-dnsop-edns-key-tag-04.txt >
	Internet Engineering Task Force D. Wessels		Internet Engineering Task Force D. Wessels
	Internet-Draft Verisign		Internet-Draft Verisign
	Intended status: Standards Track W. Kumari		Intended status: Standards Track W. Kumari
	Expires: April 8, 2017 Google		Expires: July 21, 2017 Google
	P. Hoffman		P. Hoffman
	ICANN		ICANN
	October 5, 2016		January 17, 2017
	Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)		Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
	draft-ietf-dnsop-edns-key-tag-03		draft-ietf-dnsop-edns-key-tag-04
	Abstract		Abstract
	The DNS Security Extensions (DNSSEC) were developed to provide origin		The DNS Security Extensions (DNSSEC) were developed to provide origin
	authentication and integrity protection for DNS data by using digital		authentication and integrity protection for DNS data by using digital
	signatures. These digital signatures can be verified by building a		signatures. These digital signatures can be verified by building a
	chain-of-trust starting from a trust anchor and proceeding down to a		chain-of-trust starting from a trust anchor and proceeding down to a
	particular node in the DNS. This document specifies two different		particular node in the DNS. This document specifies two different
	ways for validating resolvers to signal to a server which keys are		ways for validating resolvers to signal to a server which keys are
	referenced in their chain-of-trust. The data from such signaling		referenced in their chain-of-trust (see Section 1.1 for the
	allow zone administrators to monitor the progress of rollovers in a		rationale). The data from such signaling allow zone administrators
	DNSSEC-signed zone.		to monitor the progress of rollovers in a DNSSEC-signed zone.
	This document describes two independent methods for validating
	resolvers to publish their referenced keys: an EDNS option and a
	different DNS query. The reason there are two methods instead of one
	is some people see significant problems with each method. Having two
	methods is clearly worse than having just one, but it is probably
	better for the Internet than having no way to gain the information
	from the resolvers.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 8, 2017.		This Internet-Draft will expire on July 21, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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. Design Evolution . . . . . . . . . . . . . . . . . . . . 3		1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4		2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5		4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5
	4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5		4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5
	4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6		4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6
	4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6		4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6
	4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6		4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6
	4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 7		4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 6
	4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7		4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 7
	4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7		4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7
	4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7		4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7
	5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8		5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 8
	5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8		5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8		5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8
	5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 9		5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 8
	5.3.1. Interaction With Aggressive Negative Caching . . . . 9		5.3.1. Interaction With Aggressive Negative Caching . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12		Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and		The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and
	[RFC4035] were developed to provide origin authentication and		[RFC4035] were developed to provide origin authentication and
	integrity protection for DNS data by using digital signatures.		integrity protection for DNS data by using digital signatures.
	DNSSEC uses Key Tags to efficiently match signatures to the keys from		DNSSEC uses Key Tags to efficiently match signatures to the keys from
	which they are generated. The Key Tag is a 16-bit value computed		which they are generated. The Key Tag is a 16-bit value computed
	from the RDATA portion of a DNSKEY RR using a formula not unlike a		from the RDATA portion of a DNSKEY RR using a formula not unlike a
	ones-complement checksum. RRSIG RRs contain a Key Tag field whose		ones-complement checksum. RRSIG RRs contain a Key Tag field whose
	value is equal to the Key Tag of the DNSKEY RR that validates the		value is equal to the Key Tag of the DNSKEY RR that validates the
	signature.		signature.
	Likewise, Delegation Signer (DS) RRs also contain a Key Tag field		Likewise, Delegation Signer (DS) RRs also contain a Key Tag field
	whose value is equal to the Key Tag of the DNSKEY RR to which it		whose value is equal to the Key Tag of the DNSKEY RR to which it
	refers.		refers.
	This draft sets out to specify a way for validating resolvers to tell		This document specifies how validating resolvers can tell a server,
	a server in a DNS query which DNSSEC key(s) they would use to		in a DNS query, which DNSSEC key(s) they would use to validate the
	validate responses from that zone. This is done in two ways: using		server's responses. It describes two independent methods for
	an EDNS option for use in the OPT meta-RR [RFC6891] that contains the		conveying Key Tag information bewteen clients and servers: placing an
	key tags (described in Section 4), and by periodically sending		EDNS option in the OPT meta-RR [RFC6891] that contains the key tags
	special "key tag queries" to a server authoritative for the zone		(described in Section 4), and by periodically sending special "key
	(described in Section 5).		tag queries" to a server authoritative for the zone (described in
			Section 5).
	Each of these new signaling mechanisms is OPTIONAL to implement and		Each of these new signaling mechanisms is OPTIONAL to implement and
	use. These mechanisms serve to measure the acceptance and use of new		use. These mechanisms serve to measure the acceptance and use of new
	DNSSEC trust anchors and key signing keys (KSKs). This signaling		DNSSEC trust anchors and key signing keys (KSKs). This signaling
	data can be used by zone administrators as a gauge to measure the		data can be used by zone administrators as a gauge to measure the
	successful deployment of new keys. This is of particular interest		successful deployment of new keys. This is of particular interest
	for the DNS root zone in the event of key and/or algorithm rollovers		for the DNS root zone in the event of key and/or algorithm rollovers
	that rely on [RFC5011] to automatically update a validating DNS		that rely on [RFC5011] to automatically update a validating DNS
	resolver's trust anchor.		resolver's trust anchor.
	This document does not introduce new processes for rolling keys or		This document does not introduce new processes for rolling keys or
	updating trust anchors. Rather, it specifies a means by which a DNS		updating trust anchors. Rather, it specifies a means by which a DNS
	query can signal the set of keys that a client uses for DNSSEC		query can signal the set of keys that a client uses for DNSSEC
	validation.		validation.
	1.1. Design Evolution		1.1. Design Evolution
	Initially this document was named draft-edns-key-tag and proposed		Initially, when the work on this document started, it proposed
	including Key Tag values in a new EDNS(0) option code. It was		including Key Tag values in a new EDNS(0) option code. It was
	modeled after [RFC6975], which provides DNSSEC algorithm signaling.		modeled after [RFC6975], which provides DNSSEC algorithm signaling.
	The authors received feedback from Working Group participants that it		The authors received feedback from dnsop Working Group participants
	might be better to convey Key Tags in QNAME of a separate DNS query,		that it might be better to convey Key Tags in QNAME of a separate DNS
	rather than as an EDNS(0) option. Mostly this is because forwarding		query, rather than as an EDNS(0) option. Mostly this is because
	(e.g. from stub to recursive to authoritative) could be problematic.		forwarding (e.g. from stub to recursive to authoritative) could be
	Reasons include:		problematic. Reasons include:
	1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not		1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not
	be forwarded by default, as per [RFC6891].		be forwarded by default, as per [RFC6891].
	2. Middleboxes might block entire queries containing unknown EDNS(0)		2. Middleboxes might block entire queries containing unknown EDNS(0)
	option codes.		option codes.
	3. A recursive might need to remember Key Tag values (i.e., keep		3. A recursive might need to remember Key Tag values (i.e., keep
	state) received from its stub clients and then forward them at a		state) received from its stub clients and then forward them at a
	later opportunity.		later opportunity.
	skipping to change at page 11, line 23 ¶		skipping to change at page 11, line 21 ¶
	Scott Rose and Steve Crocker. The authors would like to thank Mark		Scott Rose and Steve Crocker. The authors would like to thank Mark
	Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim		Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim
	Wicinski, Suzanne Woolf, and other members of the dnsop working group		Wicinski, Suzanne Woolf, and other members of the dnsop working group
	for their input.		for their input.
	10. References		10. References
	10.1. Normative References		10.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, November 1987.
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119, March 1997.
	DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements", RFC
	RFC 4033, DOI 10.17487/RFC4033, March 2005,		4033, March 2005.
	<http://www.rfc-editor.org/info/rfc4033>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, March 2005.
	<http://www.rfc-editor.org/info/rfc4034>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, March 2005.
	<http://www.rfc-editor.org/info/rfc4035>.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891,		for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
	DOI 10.17487/RFC6891, April 2013,
	<http://www.rfc-editor.org/info/rfc6891>.
	10.2. Informative References		10.2. Informative References
	[draft-ietf-dnsop-nsec-aggressiveuse]
	Fujiwara, K., "Aggressive use of NSEC/NSEC3", 2016.
	[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)		[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
	Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,		Trust Anchors", STD 74, RFC 5011, September 2007.
	September 2007, <http://www.rfc-editor.org/info/rfc5011>.
	[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic		[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic
	Algorithm Understanding in DNS Security Extensions		Algorithm Understanding in DNS Security Extensions
	(DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,		(DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
	<http://www.rfc-editor.org/info/rfc6975>.		<http://www.rfc-editor.org/info/rfc6975>.
			[draft-ietf-dnsop-nsec-aggressiveuse]
			Fujiwara, K., "Aggressive use of NSEC/NSEC3", 2016.
	Appendix A. Changes / Author Notes.		Appendix A. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication]		[RFC Editor: Please remove this section before publication]
	From -01 to -02:		From -01 to -02:
	o Added QNAME-based method of signaling key tags.		o Added QNAME-based method of signaling key tags.
	o Added Paul Hoffman as coauthor.		o Added Paul Hoffman as coauthor.
End of changes. 23 change blocks.
	54 lines changed or deleted		38 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/