< draft-ietf-dnsop-kskroll-sentinel-05.txt		draft-ietf-dnsop-kskroll-sentinel-06.txt >
	DNSOP G. Huston		DNSOP G. Huston
	Internet-Draft J. Damas		Internet-Draft J. Damas
	Intended status: Standards Track APNIC		Intended status: Standards Track APNIC
	Expires: September 6, 2018 W. Kumari		Expires: September 6, 2018 W. Kumari
	Google		Google
	March 5, 2018		March 5, 2018
	A Sentinel for Detecting Trusted Keys in DNSSEC		A Sentinel for Detecting Trusted Keys in DNSSEC
	draft-ietf-dnsop-kskroll-sentinel-05		draft-ietf-dnsop-kskroll-sentinel-06
	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 a mechanism that		particular node in the DNS. This document specifies a mechanism that
	will allow an end user and third parties to determine the trusted key		will allow an end user and third parties to determine the trusted key
	state for the root key of the resolvers that handle that user's DNS		state for the root key of the resolvers that handle that user's DNS
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	and checking which result in a SERVFAIL.		and checking which result in a SERVFAIL.
	Note that the sentinel mechanism described here measures a very		Note that the sentinel mechanism described here measures a very
	different (and likely more useful) metric than [RFC8145]. RFC 8145		different (and likely more useful) metric than [RFC8145]. RFC 8145
	relies on resolvers reporting the list of keys that they have to root		relies on resolvers reporting the list of keys that they have to root
	servers. That reflects on how many resolvers will be impacted by a		servers. That reflects on how many resolvers will be impacted by a
	KSK roll, but not what the user impact of the KSK roll will be.		KSK roll, but not what the user impact of the KSK roll will be.
	3. Sentinel Mechanism in Resolvers		3. Sentinel Mechanism in Resolvers
	DNSSEC-Validating resolvers that implement this mechanism MUST be		DNSSEC-Validating resolvers that implement this mechanism MUST
	performing validation of responses in accordance with the DNSSEC		perform validation of responses in accordance with the DNSSEC
	response validation specification [RFC4035].		response validation specification [RFC4035].
	This sentinel mechanism makes use of two special labels:		This sentinel mechanism makes use of two special labels:
	o kskroll-sentinel-is-ta-<key-tag>		o kskroll-sentinel-is-ta-<key-tag>
	o kskroll-sentinel-not-ta-<key-tag>		o kskroll-sentinel-not-ta-<key-tag>
	Note that the <key-tag> is specified in the DNS label as unsigned		Note that the <key-tag> is specified in the DNS label as unsigned
	decimal integer (as described in [RFC4034], section 5.3), but zero-		decimal integer (as described in [RFC4034], section 5.3), but zero-
	padded to five digits (i.e: 42 would be represented as 00042).		padded to five digits (for example, a Key Tag 42 would be represented
			in the label as 00042).
	These labels trigger special processing in the resolver as specified
	bellow. The labels containing "is-ta" and "not-ta" are used to
	answer questions "Is (or is not, respectivaly) this the key tag a
	trust anchor which the validating DNS resolver is currently
	trusting?" Processing of both labels has the very same preconditions
	for both labels and differs only in last step.
	The use of the positive question and its inverse allows for queries		These labels trigger special processing in the resolver when
	to detect whether resolvers support this sentinel mechanism.		responses from authoritative servers are received. Labels containing
			"kskroll-sentinel-is-ta-<key-tag>" is used to answer the question "Is
			this the Key Tag a trust anchor which the validating DNS resolver is
			currently trusting?" Labels containing "kskroll-sentinel-not-ta-
			<key-tag>" is used to answer the question "Is this the Key Tag *not*
			a trust anchor which the validating DNS resolver is currently
			trusting?"
	3.1. Preconditions		3.1. Preconditions
	All of the following conditions must be met to trigger special		All of the following conditions must be met to trigger special
	processing inside resolver code:		processing inside resolver code:
	a. DNS response for particular query is DNSSEC validated and result		o The DNS response is DNSSEC validated and result of validation is
	of validation is SECURE.		"Secure"
	b. QTYPE is A or AAAA (Query Type value 1 or 28)		o The QTYPE is either A or AAAA (Query Type value 1 or 28)
	c. The OPCODE is QUERY		o The OPCODE is QUERY
	d. The leftmost label of the QNAME is either "kskroll-sentinel-is-		o The leftmost label of the QNAME is either "kskroll-sentinel-is-ta-
	ta-<tag-index>" or "kskroll-sentinel-not-ta-<tag-index>"		<key-tag>" or "kskroll-sentinel-not-ta-<key-tag>"
	If all preconditions are not met, the resolver MUST NOT alter the DNS		If any one of the preconditions is not met, the resolver MUST NOT
	response.		alter the DNS response based on the mechanism in this document.
	3.2. Special processing		3.2. Special processing
	Responses which fullfill all preconditions in section 3.1 are subject		Responses which fullfill all of the preconditions in Section 3.1
	of special processing, depending on leftmost label of the QNAME.		require special processing, depending on leftmost label in the QNAME.
	First, the resolver determines if the numerical value of <key-tag> is		First, the resolver determines if the numerical value of <key-tag> is
	equal to any of the key tags of an active Root Zone Key Signing Key		equal to any of the Key Tags of an active root zone KSK which is
	which is currently trusted by the local resolver and is stored in its		currently trusted by the local resolver and is stored in its store of
	store of trusted keys. An active key is one which could currently be		trusted keys. An active key is one which could currently be used for
	used for validation (that is, a key that is not in either the AddPend		validation (that is, a key that is not in either the AddPend or
	or Revoked state as described in [RFC5011]).		Revoked state as described in [RFC5011]).
	As second step, the resolver alters response depending on meaning of		Second, the resolver alters the response being sent to the original
	the label and presence of key with given keytag among trusted keys.		query based on both the left-most label and the presence of a key
	Two labels and two possible states of the keytag generate four		with given Key Tag in the trust anchor store. Two labels and two
	possible combinations summarized in the table:		possible states of the keytag generate four possible combinations
			summarized in the table:
	Keytag trusted		| Key Tag is trusted | Key Tag is not trusted
	label type | yes | no		------------------------------------------------------------------
	--------------------------------------------------------------		is-ta | return original answer | return SERVFAIL
	is-ta | return original answer | return SERVFAIL		not-ta | return SERVFAIL | return original answer
	not-ta | return SERVFAIL | return original answer
	4. Processing Sentinel Results		4. Processing Sentinel Results
	This proposed test that uses the sentinel detection mechanism		This proposed test that uses the sentinel detection mechanism
	described in this document is based on the use of three DNS names		described in this document is based on the use of three DNS names
	that have three distinct DNS resolution behaviours. The test is		that have three distinct DNS resolution behaviours. The test is
	intended to allow a user or a third party to determine the state of		intended to allow a user or a third party to determine the state of
	their DNS resolution system, and, in particular, whether or not they		their DNS resolution system, and, in particular, whether or not they
	are using validating DNS resolvers that use a particular trust anchor		are using validating DNS resolvers that use a particular trust anchor
	for the root zone.		for the root zone.
	skipping to change at page 12, line 18 ¶		skipping to change at page 12, line 18 ¶
	Wessels for providing comments in the form of a pull request. Petr		Wessels for providing comments in the form of a pull request. Petr
	Specek implmented early versions of this technique into the Knot		Specek implmented early versions of this technique into the Knot
	resolver, identified a number of places where it wasn't clear, and		resolver, identified a number of places where it wasn't clear, and
	provided very helpful text to address this.		provided very helpful text to address this.
	10. Change Log		10. Change Log
	Note that this document is being worked on in GitHub - see Abstract.		Note that this document is being worked on in GitHub - see Abstract.
	The below is mainly large changes, and is not authoritative.		The below is mainly large changes, and is not authoritative.
			From -05 to -06:
			Paul improved my merging of Petr's text to make it more readable.
			Minor change, but this is just before the cut-off, so I wanted it
			maximally readable.
	From -04 to -05:		From -04 to -05:
	o Incorporated Duane's #10		o Incorporated Duane's #10
	o Integrated Petr Spacek's Issue - https://github.com/APNIC-Labs/		o Integrated Petr Spacek's Issue - https://github.com/APNIC-Labs/
	draft-kskroll-sentinel/issues/9 (note that commit-log incorrectly		draft-kskroll-sentinel/issues/9 (note that commit-log incorrectly
	referred to Duane's PR as number 9, it is actually 10).		referred to Duane's PR as number 9, it is actually 10).
	From -03 to -04:		From -03 to -04:
	skipping to change at page 14, line 9 ¶		skipping to change at page 14, line 19 ¶
	[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, DOI 10.17487/RFC4035, March 2005,
	<https://www.rfc-editor.org/info/rfc4035>.		<https://www.rfc-editor.org/info/rfc4035>.
	[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, <https://www.rfc-editor.org/info/rfc5011>.		September 2007, <https://www.rfc-editor.org/info/rfc5011>.
	[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
	Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
	DOI 10.17487/RFC6840, February 2013, <https://www.rfc-
	editor.org/info/rfc6840>.
	11.2. Informative References		11.2. Informative References
	[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust		[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
	Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC		Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC
	8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-		8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-
	editor.org/info/rfc8145>.		editor.org/info/rfc8145>.
	Authors' Addresses		Authors' Addresses
	Geoff Huston		Geoff Huston
End of changes. 16 change blocks.
	42 lines changed or deleted		44 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/