< draft-ietf-dnsop-edns-key-tag-02.txt		draft-ietf-dnsop-edns-key-tag-03.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: January 9, 2017 Google		Expires: April 8, 2017 Google
	P. Hoffman		P. Hoffman
	ICANN		ICANN
	July 8, 2016		October 5, 2016
	Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)		Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
	draft-ietf-dnsop-edns-key-tag-02		draft-ietf-dnsop-edns-key-tag-03
	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. The data from such signaling
	allow zone administrators to monitor the progress of rollovers in a		allow zone administrators to monitor the progress of rollovers in a
	DNSSEC-signed zone.		DNSSEC-signed zone.
	This document describes two independent methods for validating		This document describes two independent methods for validating
	resolvers to publish their referenced keys: an EDNS option and a		resolvers to publish their referenced keys: an EDNS option and a
	differnt DNS query. The reason there are two methods instead of one		different DNS query. The reason there are two methods instead of one
	is some people see significant problems with each method. Having two		is some people see significant problems with each method. Having two
	methods is clearly worse than having just one, but it is probably		methods is clearly worse than having just one, but it is probably
	better for the Internet than having no way to gain the information		better for the Internet than having no way to gain the information
	from the resolvers.		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 January 9, 2017.		This Internet-Draft will expire on April 8, 2017.
	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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . 6		4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . . 8		5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	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 . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 12
	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
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	only sending QNAME-based key tag queries for configured trust		only sending QNAME-based key tag queries for configured trust
	anchors, although EDNS-based key tags can be sent with any DNSKEY		anchors, although EDNS-based key tags can be sent with any DNSKEY
	query.		query.
	Another downside to the QNAME-based approach is that since the trust		Another downside to the QNAME-based approach is that since the trust
	anchor zone might not contain labels matching the QNAME, these		anchor zone might not contain labels matching the QNAME, these
	queries could be subject to aggressive negative caching features now		queries could be subject to aggressive negative caching features now
	in development by the Working Group. This could affect the amount of		in development by the Working Group. This could affect the amount of
	signaling sent by some clients compared to others.		signaling sent by some clients compared to others.
			A probably minor downside to the QNAME-based approach is that it
			cannot be used with extremely long query names if the addition of the
			prefix would cause the name to be longer than 255 octets.
	2. Requirements Terminology		2. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Terminology		3. Terminology
	Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.		Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.
	A validating security-aware resolver uses this public key or hash		A validating security-aware resolver uses this public key or hash
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 16 ¶
	response.		response.
	5. Using the Key Tag Query		5. Using the Key Tag Query
	5.1. Query Format		5.1. Query Format
	A key tag query consists of a standard DNS query of type NULL and of		A key tag query consists of a standard DNS query of type NULL and of
	class IN [RFC1035].		class IN [RFC1035].
	The first component of the query name is the string "_ta-" followed		The first component of the query name is the string "_ta-" followed
	by a hyphen-separated list of hexadecimal-encoded Key Tag values.		by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
	The zone name corresponding to the trust anchor is appended to this		values. The zone name corresponding to the trust anchor is appended
	first component.		to this first component.
	For example, a validating DNS resolver that has a single root zone		For example, a validating DNS resolver that has a single root zone
	trust anchor with key tag 17476 (decimal) would originate a query of		trust anchor with key tag 17476 (decimal) would originate a query of
	the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.		the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.
	A validating DNS resolver that has a three trust anchors for the		Hexadecimal values MUST be zero-padded. For example, if the key tag
	example.com zone with key tags 31589, 43547, 31406 (decimal) would		is 999 (decimal), it is represented in hexadecimal as 03e7.
	originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-7b65-
	aa1b-7aa3.example.com.		When representing multiple key tag values, they MUST be sorted in
			order from smallest to largest. For example, A validating DNS
			resolver that has a three trust anchors for the example.com zone with
			key tags 1589, 43547, 31406 (decimal) would originate a query of the
			form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com.
	5.2. Use By Queriers		5.2. Use By Queriers
	A validating DNS resolver (stub or recursive) SHOULD originate a key		A validating DNS resolver (stub or recursive) SHOULD originate a key
	tag query whenever it also originates a DNSKEY query for a configured		tag query whenever it also originates a DNSKEY query for a configured
	Trust Anchor zone. In other words, the need to issue a DNSKEY query		Trust Anchor zone. In other words, the need to issue a DNSKEY query
	is also the trigger to issue a key tag query.		is also the trigger to issue a key tag query.
	The value(s) included in the key tag query represent the Key Tag(s)		The value(s) included in the key tag query represent the Key Tag(s)
	of the Trust Anchor that will be used to validate the expected DNSKEY		of the Trust Anchor that will be used to validate the expected DNSKEY
	skipping to change at page 8, line 52 ¶		skipping to change at page 9, line 12 ¶
	DNS resolvers with caches SHOULD cache and reuse the response to a		DNS resolvers with caches SHOULD cache and reuse the response to a
	key tag query just as it would any other response.		key tag query just as it would any other response.
	5.3. Use By Responders		5.3. Use By Responders
	An authoritative name server receiving key tag queries MAY log or		An authoritative name server receiving key tag queries MAY log or
	otherwise collect the Key Tag values to provide information to the		otherwise collect the Key Tag values to provide information to the
	zone operator.		zone operator.
	An authoritative name server MUST generate an appropriate response to		An authoritative name server MUST generate an appropriate response to
	the key tag query. Unless the zone operator has intentionally added		the key tag query. A server does not need to have built-in logic
	"_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN		that determines the response to key tag queries: the response code is
	response. The zone operator might want to add specific key tag		determined by whether the data is in the zone file or covered by
			wildcard. The zone operator might want to add specific key tag
	records to its zone, perhaps with specific TTLs, to affect the		records to its zone, perhaps with specific TTLs, to affect the
	frequency of key tag queries from clients. [ Note RFC1035 says NULL		frequency of key tag queries from clients. [ Note RFC1035 says NULL
	RRs are not allowed in master files, but I believe that to be		RRs are not allowed in master files, but I believe that to be
	incorrect ]		incorrect ]
	5.3.1. Interaction With Aggressive Negative Caching		5.3.1. Interaction With Aggressive Negative Caching
	Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec-		Aggressive NSEC/NSEC3 negative caching
	aggressiveuse] may also affect the quality of key tag signaling.		[draft-ietf-dnsop-nsec-aggressiveuse] may also affect the quality of
	When the response code for a key tag query is NXDOMAIN, DNS resolvers		key tag signaling. When the response code for a key tag query is
	that implement aggressive negative caching will send fewer key tag		NXDOMAIN, DNS resolvers that implement aggressive negative caching
	queries than resolvers that do not implement it.		will send fewer key tag queries than resolvers that do not implement
			it.
	For this reason, zone operators might choose to create records		For this reason, zone operators might choose to create records
	corresponding to expected key tag queries. During a rollover from		corresponding to expected key tag queries. During a rollover from
	key tag 1111 (hex) to key tag 2222 (hex), the zone could include the		key tag 1111 (hex) to key tag 2222 (hex), the zone could include the
	following records:		following records:
	_ta-1111 IN NULL \# 0		_ta-1111 IN NULL \# 0
	_ta-2222 IN NULL \# 0		_ta-2222 IN NULL \# 0
	_ta-1111-2222 IN NULL \# 0		_ta-1111-2222 IN NULL \# 0
	_ta-2222-1111 IN NULL \# 0
	[ most likely someone will suggest that key tag values should be		Recall that when multiple key tags are present, the originating
	ordered to reduce the record count from 4 to 3 ]		client MUST sort them from smallest to largest in the query name.
	6. IANA Considerations		6. IANA Considerations
	The IANA is directed to assign an EDNS0 option code for the edns-key-		The IANA is directed to assign an EDNS0 option code for the edns-key-
	tag option from the DNS EDNS0 Option Codes (OPT) registry as follows:		tag option from the DNS EDNS0 Option Codes (OPT) registry as follows:
	+-------+--------------+----------+-----------------+		+-------+--------------+----------+-----------------+
	| Value | Name | Status | Reference |		| Value | Name | Status | Reference |
	+-------+--------------+----------+-----------------+		+-------+--------------+----------+-----------------+
	| [TBA] | edns-key-tag | Optional | [This document] |		| [TBA] | edns-key-tag | Optional | [This document] |
	skipping to change at page 11, line 48 ¶		skipping to change at page 12, line 7 ¶
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<http://www.rfc-editor.org/info/rfc4035>.		<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,
	DOI 10.17487/RFC6891, April 2013,		DOI 10.17487/RFC6891, April 2013,
	<http://www.rfc-editor.org/info/rfc6891>.		<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, DOI 10.17487/RFC5011,
	September 2007, <http://www.rfc-editor.org/info/rfc5011>.		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>.
	Appendix A. Changes / Author Notes.		Appendix A. Changes / Author Notes.
End of changes. 17 change blocks.
	27 lines changed or deleted		39 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/