< draft-ietf-dnsop-rfc5011-security-considerations-00.txt		draft-ietf-dnsop-rfc5011-security-considerations-01.txt >
	dnsop W. Hardaker		dnsop W. Hardaker
	Internet-Draft Parsons, Inc.		Internet-Draft USC/ISI
	Intended status: Standards Track W. Kumari		Intended status: Standards Track W. Kumari
	Expires: October 5, 2017 Google		Expires: November 21, 2017 Google
	April 3, 2017		May 20, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-ietf-dnsop-rfc5011-security-considerations-00		draft-ietf-dnsop-rfc5011-security-considerations-01
	Abstract		Abstract
	This document describes the math behind the minimum time-length that		This document describes the math behind the minimum time-length that
	a DNS zone publisher must wait before using a new DNSKEY to sign		a DNS zone publisher must wait before using a new DNSKEY to sign
	records when supporting the RFC5011 rollover strategies.		records when supporting the RFC5011 rollover strategies.
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 5, 2017.		This Internet-Draft will expire on November 21, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Document History and Motivation . . . . . . . . . . . . . 2
			1.2. Safely Rolling the Root Zone's KSK in 2017/2018 . . . . . 3
			1.3. Requirements notation . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Timing associated with RFC5011 processing . . . . . . . . . . 3		4. Timing Associated with RFC5011 Processing . . . . . . . . . . 4
	5. Denial of Service Attack Considerations . . . . . . . . . . . 4		4.1. Timing Associated with Publication . . . . . . . . . . . 4
	5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 4		4.2. Timing Associated with Revocation . . . . . . . . . . . . 4
	5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 5		5. Denial of Service Attack Considerations . . . . . . . . . . . 5
	6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 6		5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6
	8. Operational Considerations . . . . . . . . . . . . . . . . . 8		6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Operational Considerations . . . . . . . . . . . . . . . . . 9
	11. Normative References . . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		11. Normative References . . . . . . . . . . . . . . . . . . . . 9
			Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 10
			Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	RFC5011 [RFC5011] defines a mechanism by which DNSSEC validators can		[RFC5011] defines a mechanism by which DNSSEC validators can extend
	extend their list of trust anchors when they've seen a new key		their list of trust anchors when they've seen a new key published in
	published in a zone. However, RFC5011 [intentionally] provides no		a zone. However, RFC5011 [intentionally] provides no guidance to the
	guidance to the publishers of DNSKEYs about how long they must wait		publishers of DNSKEYs about how long they must wait before switching
	before switching to the newly published key for signing records.		to a newly published key for signing records or how long they must
	Because of this lack of guidance, zone publishers may derive		wait before removing a revoked key from a zone. Because of this lack
	incorrect assumptions about safe usage of the RFC5011 DNSKEY		of guidance, zone publishers may derive incorrect assumptions about
	advertising and rolling process. This document describes the minimum		safe usage of the RFC5011 DNSKEY advertising, rolling and revocation
	security requirements from a publishers point of view and is intended		process. This document describes the minimum security requirements
	to compliment the guidance offered in RFC5011 (which is written to		from a publisher's point of view and is intended to compliment the
	provide timing guidance solely to the Validating Resolvers point of		guidance offered in RFC5011 (which is written to provide timing
	view).		guidance solely to a Validating Resolver's point of view).
			1.1. Document History and Motivation
	To verify this lack of understanding is wide-spread, the authors		To verify this lack of understanding is wide-spread, the authors
	reached out to 5 DNSSEC experts to ask them how long they thought		reached out to 5 DNSSEC experts to ask them how long they thought
	they must wait before using a new KSK that was being rolled according		they must wait before signing a zone using a new KSK [RFC4033] that
	to the 5011 process. All 5 experts answered with an insecure value,		was being rolled according to the 5011 process. All 5 experts
	and thus we have determined that this lack of operational guidance is		answered with an insecure value, and we determined that this lack of
	causing security concerns today. We hope that this document will		operational guidance is causing security concerns today and wrote
			this companion document to RFC5011. We hope that this document will
	rectify this understanding and provide better guidance to zone		rectify this understanding and provide better guidance to zone
	publishers that wish to make use of the RFC5011 rollover process.		publishers that wish to make use of the RFC5011 rollover process.
	One important note about ICANN's upcoming 2017 KSK rollover plan for		1.2. Safely Rolling the Root Zone's KSK in 2017/2018
	the root zone: the timing values chosen for rolling the KSK in the
	root zone appear completely safe, and are not in any way affected by
	the timing concerns introduced by this draft
	1.1. Requirements notation		One important note about ICANN's [currently upcoming] 2017/2018 KSK
			rollover plan for the root zone: the timing values chosen for rolling
			the KSK in the root zone appear completely safe, and are not affected
			by the timing concerns introduced by this draft
			1.3. Requirements notation
	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].
	2. Background		2. Background
	The RFC5011 process describes a process by which a Validating		The RFC5011 process describes a process by which a Validating
	Resolver may accept a newly published KSK as a trust anchor for		Resolver may accept a newly published KSK as a trust anchor for
	validating future DNSSEC signed records. This document augments that		validating future DNSSEC signed records. It also describes the
	information with additional constraints, as required from the DNSKEY		process for publicly revoking a published KSK. This document
	publication point of view. Note that it does not define any other		augments that information with additional constraints, as required
	operational guidance or recommendations about the RFC5011 process		from the DNSKEY publication and revocation's points of view. Note
	from a publication point of view and restricts itself to solely the		that it does not define any other operational guidance or
	security and operational ramifications of switching to a new key too		recommendations about the RFC5011 process and restricts itself to
	soon. Failure of a DNSKEY publisher to follow the minimum		solely the security and operational ramifications of switching to a
	recommendations associated with this draft will result in potential		new key or removing a revoked key too soon. Failure of a DNSKEY
	denial-of-service attack opportunities against validating resolvers.		publisher to follow the minimum recommendations associated with this
			draft will result in potential denial-of-service attack opportunities
			against validating resolvers or in revoked old DNSKEYs remaining in
			the trust anchor storage of validating resolvers beyond their
			expected valid lifetime.
	3. Terminology		3. Terminology
	Trust Anchor Publisher The entity responsible for publishing a		Trust Anchor Publisher The entity responsible for publishing a
	DNSKEY that can be used as a trust anchor.		DNSKEY that can be used as a trust anchor.
	4. Timing associated with RFC5011 processing		Zone Signer The owner of a zone intending to publish a new Key-
			Signing-Key (KSK) that will become a trust anchor by validators
			following the RFC5011 process.
			RFC5011 Validating Resolver A DNSSEC Validating Resolver that is
			using the RFC5011 processes to track and update trust anchors.
			Sometimes referred to as a "RFC5011 Resolver"
			Attacker An attacker intent on foiling the RFC5011 Validator's
			ability to successfully adopt the Zone Signer's new DNSKEY as a
			new trust anchor or to prevent the RFC5011 Validator from removing
			an old DNSKEY from its list of trust anchors.
			Also see Section 2 of [RFC4033] and [RFC7719] for additional
			terminology.
			4. Timing Associated with RFC5011 Processing
			4.1. Timing Associated with Publication
	RFC5011's process of safely publishing a new key and then making use		RFC5011's process of safely publishing a new key and then making use
	of that key falls into a number of high-level steps:		of that key falls into a number of high-level steps to be performed
			by the Trust Anchor Publisher:
	1. Publish a new DNSKEY in the zone but continue to sign with the		1. Publish a new DNSKEY in the zone, but continue to sign the zone
	old one.		with the old one.
	2. Wait a period of time.		2. Wait a period of time.
	3. Begin using the new DNSKEY to sign the appropriate resource		3. Begin using the new DNSKEY to sign the appropriate resource
	records.		records.
	4. Optionally mark the older DNSKEY as revoked and publish the
	revoked key.
	This document discusses step 2 of the above process. Some		This document discusses step 2 of the above process. Some
	interpretations of RFC5011 have erroneously determined that the wait		interpretations of RFC5011 have erroneously determined that the wait
	time is equal to RFC5011's "hold down time".		time is equal to RFC5011's "hold down time".
	This document describes an attack based on this (common) erroneous		Section 5 describes an attack based on this (common) erroneous
	belief, which results in a denial of service attack against the zone		belief, which results in a denial of service attack against the zone
	if that value is used.		if that value is used.
			4.2. Timing Associated with Revocation
			RFC5011's process of advertising that an old key is to be revoked
			from RFC5011 validating resolvers falls into a number of high-level
			steps:
			1. Set the revoke bit on the DNSKEY to be revoked.
			2. Sign the revoked DNSKEY with itself.
			3. Wait a period of time.
			4. Remove the revoked key from the zone.
			This document discusses step 3 of the above process. Some
			interpretations of RFC5011 have erroneously determined that the wait
			time is equal to RFC5011's "hold down time".
			This document describes an attack based on this (common) erroneous
			belief, which results in a revoked DNSKEY potentially staying in a
			RFC5011 validating resolver long past its expected usage.
	5. Denial of Service Attack Considerations		5. Denial of Service Attack Considerations
	If an attacker is able to provide a RFC5011 validating engine with		If an attacker is able to provide a RFC5011 Validating Resolver with
	past responses, such as when it is in-path or able to otherwise		past responses, such as when it is in-path or able to otherwise
	perform any number of cache poisoning attacks, the attacker may be		perform any number of cache poisoning attacks, the attacker may be
	able to leave the RFC5011-compliant validator without an appropriate		able to leave compliant RFC5011-Validating Resolvers without an
	DNSKEY trust anchor. This scenario will remain until an		appropriate DNSKEY trust anchor. This scenario will remain until an
	administrator manually fixes the situation.		administrator manually fixes the situation.
	The following timeline illustrates this situation.		The following timeline illustrates this situation.
	5.1. Enumerated Attack Example		5.1. Enumerated Attack Example
	The following example settings are used in the example scenario		The following example settings are used in the example scenario
	within this section:		within this section:
	TTL (all records) 1 day		TTL (all records) 1 day
	DNSKEY RRSIG Signature Validity 10 days		DNSKEY RRSIG Signature Validity 10 days
	Zone resigned every 1 day		Zone resigned every 1 day
	Given these settings, the following sequence of events depicts how a		Given these settings, the sequence of events in Section 5.1.1 depicts
	Trust Anchor Publisher that waits for only the RFC5011 hold time		how a Trust Anchor Publisher that waits for only the RFC5011 hold
	timer length of 30 days subjects its users to a potential Denial of		time timer length of 30 days subjects its users to a potential Denial
	Service attack. The timing schedule listed below is based on a new		of Service attack. The timing schedule listed below is based on a
	trust anchor (a Key Signing Key (KSK)) being published at time T+0.		Trust Anchor Publisher publishing a new Key Signing Key (KSK), with
	All numbers in this sequence refer to days before and after such an		the intent that it will later become a trust anchor. We label this
	event. Thus, T-1 is the day before the introduction of the new key,		publication time as "T+0". All numbers in this sequence refer to
	and T+15 is the 15th day after the key was introduced into the		days before and after this initial publication event. Thus, T-1 is
	fictitious zone being discussed.		the day before the introduction of the new key, and T+15 is the 15th
			day after the key was introduced into the fictitious zone being
			discussed.
	In this dialog, we consider two keys being published:		In this dialog, we consider two keys being published:
	K_old The older KSK being replaced.		K_old An older KSK and Trust Anchor being replaced.
	K_new The new KSK being transitioned into active use, using the
	RFC5011 process.
	In this dialog, the following actors are playing roles in this
	situation:
	Zone Signer The owner of a zone intending to publish a new Key-
	Signing-Key (KSK) that will become a trust anchor by validators
	following the RFC5011 process.
	RFC5011 Validator A DNSSEC validator that is using the RFC5011
	processes to track and update trust anchors.
	Attacker An attacker intent on foiling the RFC5011 Validator's		K_new A new KSK being transitioned into active use and becoming a
	ability to successfully adopt the Zone Signer's K_new key as a new		Trust Anchor via the RFC5011 process.
	trust anchor.
	5.1.1. Attack Timing Breakdown		5.1.1. Attack Timing Breakdown
	The following series of steps depicts the timeline in which an attack		The following series of steps depicts the timeline in which an attack
	occurs that foils the adoption of a new DNSKEY by a Trust Anchor		occurs that foils the adoption of a new DNSKEY by a Trust Anchor
	Publisher that revokes the old key too quickly.		Publisher that starts signing with the new DNSKEY too quickly.
	T-1 The last signatures are published by the Zone Signer that signs		T-1 The last RRSIGs are published by the Zone Signer that signs only
	only K_old using K_old. The Attacker queries for, retrieves and		K_old key using the K_old key itself. [It may also be signing
	caches this keyset and corresponding signatures.		ZSKs as well, but they are not relevant to this event so we will
			not talk further about them; we are only talking about RRSIGs that
			cover the DNSKEYs.] The Attacker queries for, retrieves and
			caches this DNSKEY set and corresponding RRSIG signatures.
	T-0 The Zone Signer adds K_new to his zone and signs the zone's key		T-0 The Zone Signer adds K_new to their zone and signs the zone's
	set with K_old. The RFC5011 Validator retrieves the new key set		key set with K_old. The RFC5011 Validator (later to be under
	and corresponding signature set and notices the publication of		attack) retrieves this new key set and corresponding RRSIGs and
	K_new. The RFC5011 Validator starts the (30-day) hold-down timer		notices the publication of K_new. The RFC5011 Validator starts
	for K_new.		the (30-day) hold-down timer for K_new.
	T+5 The RFC5011 Validator queries for the zone's keyset per the		T+5 The RFC5011 Validator queries for the zone's keyset per the
	Active Refresh schedule, discussed in Section 2.3 of RFC5011.		RFC5011 Active Refresh schedule, discussed in Section 2.3 of
	Instead of receiving the intended published keyset, the Attacker		RFC5011. Instead of receiving the intended published keyset, the
	successfully replays the keyset and associated signatures that		Attacker successfully replays the keyset and associated signatures
	they recorded at T-1. Because the signature lifetime is 10 days		that they recorded at T-1. Because the signature lifetime is 10
	(in this example), the replayed signature and keyset is accepted		days (in this example), the replayed signature and keyset is
	as valid (being only 6 days old) and the RFC5011 Validator cancels		accepted as valid (being only 6 days old) and the RFC5011
	the hold-down timer for K_new.		Validator cancels the hold-down timer for K_new, per the RFC5011
			algorithm.
	T+10 The RFC5011 Validator queries for the zone's keyset and		T+10 The RFC5011 Validator queries for the zone's keyset and
	discovers K_new again, signed by K_old (the attacker is unable to		discovers the new kset which includes K_new (again), signed by
	replay the records cached at T-1, because they have now expired).		K_old. Note: the attacker is unable to replay the records cached
	The RFC5011 Validator starts (anew) the hold-timer for K_new.		at T-1, because they have now expired. The RFC5011 Validator
			starts (anew) the hold-timer for K_new.
	T+15,T+20, and T+25 The RFC5011 Validator continues checking the		T+15,T+20, and T+25 The RFC5011 Validator continues checking the
	zone's key set and lets the hold-down timer keep running without		zone's key set at the prescribed regular intervals. The RFC5011
	resetting it.		Validator's hold-down timer keep running without being reset
			assuming all of the validations succeed (again: the attacker can
			no longer replay traffic to their benefit).
	T+30 The Zone Signer knows that this is the first time at which some		T+30 The Zone Signer knows that this is the first time at which some
	validators might accept K_new as a new trust anchor, since the		validators might accept K_new as a new trust anchor, since the
	hold-down timer of a RFC5011 Validator not under attack that had		hold-down timer of a RFC5011 Validator not under attack that had
	queried and retrieved K_new at T+0 would now have reached 30 days.		queried and retrieved K_new at T+0 would now have reached 30 days.
	However, the hold-down timer of our attacked RFC5011 Validator is		However, the hold-down timer of our attacked RFC5011 Validator is
	only at 20 days.		only at 20 days.
	T+35 The Zone Signer (mistakenly) believes that all validators		T+35 The Zone Signer (mistakenly) believes that all validators
	following the Active Refresh schedule (Section 2.3 of RFC5011)		following the Active Refresh schedule (Section 2.3 of RFC5011)
	should have accepted K_new as a the new trust anchor (since the		should have accepted K_new as a the new trust anchor (since the
	hold down time of 30 days + 1/2 the signature validity period		hold down time of 30 days + 1/2 the signature validity period
	would have passed). However, the hold-down timer of our attacked		would have passed). However, the hold-down timer of our attacked
	RFC5011 Validator is only at 25 days; The replay attack at T+5		RFC5011 Validator is only at 25 days; The replay attack at T+5
	means its new hold-time timer actually started at T+10, and thus		means its new hold-time timer actually started at T+10, and thus
	at this time it's real hold-down timer is at T+35 - T+10 = 25		at this time it's real hold-down timer is at T+35 - T+10 = 25
	days, which is less than the RFC5011 required 30 days.		days, which is less than the RFC5011 required 30 days and the
			RFC5011 won't consider it a valid trust anchor addition yet.
	T+36 The Zone Signer, believing K_new is safe to use, switches their		T+36 The Zone Signer, believing K_new is safe to use, switches their
	active signing KSK to K_new and publishes a new DNSKEY set		active signing KSK to K_new and publishes a new RRSIG, signed with
	signature signed with K_new. Non-attacked RFC5011 validators,		K_new, and covering the DNSKEY set. Non-attacked RFC5011
	with a hold-down timer of at least 30 days, would have accepted		validators, with a hold-down timer of at least 30 days, would have
	K_new into their set of trusted keys. But, because our attacked		accepted K_new into their set of trusted keys. But, because our
	RFC5011 Validator still has a hold-down timer for K_new at 26		attacked RFC5011 Validator has a hold-down timer for K_new at only
	days, it will fail to accept K_new as a trust anchor and since		26 days, it will fail to accept K_new as a trust anchor. Since
	K_old is no longer being used, all the KSK records from the zone		K_old is no longer being used, all the DNSKEY records from the
	signed by K_new will be treated as invalid. Subsequently, all		zone signed by K_new will be treated as invalid. Subsequently,
	keys in the key set are now unusable, invalidating all records in		all keys in the key set are now unusable, invalidating all of the
	the zone of any type and name.		records in the zone of any type and name.
	6. Minimum RFC5011 Timing Requirements		6. Minimum RFC5011 Timing Requirements
	Given the attack description in Section 5, the correct minimum length		Given the attack description in Section 5, the correct minimum length
	of time required for the Zone Signer to wait before using K_new is:		of time required for the Zone Signer to wait before using K_new is:
	waitTime = addHoldDownTime		waitTime = addHoldDownTime
	+ (DNSKEY RRSIG Signature Validity)		+ (DNSKEY RRSIG Signature Validity)
	+ MAX(MIN((DNSKEY RRSIG Signature Validity) / 2,		+ MAX(MIN((DNSKEY RRSIG Signature Validity) / 2,
	MAX(original TTL of K_old DNSKEY RRSet) / 2,		MAX(original TTL of K_old DNSKEY RRSet) / 2,
	15 days),		15 days),
	1 hour)		1 hour)
	+ 2 * MAX(TTL of all records)		+ 2 * MAX(TTL of all records)
	The most confusing element of the above equation comes from the "3 *
	(DNSKEY RRSIG Signature Validity) / 2" element, but is the most
	critical to understand and get right.
	The RFC5011 "Active Refresh" requirements state that:		The RFC5011 "Active Refresh" requirements state that:
	A resolver that has been configured for an automatic update		A resolver that has been configured for an automatic update
	of keys from a particular trust point MUST query that trust		of keys from a particular trust point MUST query that trust
	point (e.g., do a lookup for the DNSKEY RRSet and related		point (e.g., do a lookup for the DNSKEY RRSet and related
	RRSIG records) no less often than the lesser of 15 days, half		RRSIG records) no less often than the lesser of 15 days, half
	the original TTL for the DNSKEY RRSet, or half the RRSIG		the original TTL for the DNSKEY RRSet, or half the RRSIG
	expiration interval and no more often than once per hour.		expiration interval and no more often than once per hour.
	The important timing constraint that must be considered is the last		The important timing constraint introduced by this memo relates to
	point at which a validating resolver may have received a replayed the		the last point at which a validating resolver may have received a
	original DNSKEY set (K_old) without the new key. It's the next query		replayed the original DNSKEY set (K_old) without the new key. It's
	of the RFC5011 validator that the assured K_new will be seen. Thus,		the next query of the RFC5011 validator that the assured K_new will
	the latest time a RFC5011 validator may begin their hold down timer		be seen without a potential replay afterward. Thus, the latest time
	is an "Active Refresh" period after the last point that an attacker		a RFC5011 validator may begin their hold down timer is an "Active
	can replay the K_old DNSKEY set.		Refresh" period after the last point that an attacker can replay the
			K_old DNSKEY set.
	The "Active Refresh" interval used by RFC5011 validator is determined		The "Active Refresh" interval used by a RFC5011 validator is
	by the larger of (DNSKEY RRSIG Signature Validity) and (original TTL		determined by the larger of (DNSKEY RRSIG Signature Validity) and
	for the DNSKEY RRSet). The Following text assumes that (DNSKEY RRSIG		(original TTL for the DNSKEY RRSet). The Following text assumes that
	Signature Validity) is larger of the two, which is operationally more		(DNSKEY RRSIG Signature Validity) is larger of the two, which is
	common today.		operationally more common today.
	Thus, the worst case scenario of this attack is when the attacker can		Thus, the worst case scenario of this attack is when the attacker can
	replay K_old at just before (DNSKEY RRSIG Signature Validity). If a		replay K_old just before (DNSKEY RRSIG Signature Validity). If a
	RFC5011 validator picks up K_old at this this point, it will not have		RFC5011 validator picks up K_old at this this point, it will not have
	a hold down timer started at all. It's not until the next "Active		a hold down timer started as it will have been reset by previous
	Refresh" time that they'll pick up K_new with assurance, and thus		replays. It's not until the next "Active Refresh" time that they'll
	start their hold down timer. Thus, this is not at (DNSKEY RRSIG		pick up K_new with assurance, and thus start their (final) hold down
	Signature Validity) time past publication, but rather 3 * (DNSKEY		timer. Thus, this is not at (DNSKEY RRSIG Signature Validity) time
	RRSIG Signature Validity) / 2.		past publication but may be significantly longer based on the zone's
			DNSSEC parameters.
	The extra 2 * MAX(TTL of all records) is the standard added safety		The extra 2 * MAX(TTL of all records) is the standard added safety
	margin when dealing with DNSSEC due to caching that can take place.		margin when dealing with DNSSEC due to caching that can take place.
	Because the 5011 steps require direct validation using the signature		Because the 5011 steps require direct validation using the signature
	validity, the authors aren't yet convinced it is needed in this		validity, the authors aren't yet convinced it is needed in this
	particular case.		particular case, but it is prudent to include it for added assurance.
	For the parameters listed in Section 5.1, our example:		For the parameters listed in Section 5.1, our example:
	waitTime = 30		waitTime = 30
	+ 10		+ 10
	+ 10 / 2		+ 10 / 2
	+ 2 * (1) (days)		+ 2 * (1) (days)
	waitTime = 47 (days)		waitTime = 47 (days)
	This hold-down time of 47 days is 12 days longer than the frequently		This hold-down time of 47 days is 12 days longer than the (frequently
	perceived 35 days in T+35 above.		perceived) 35 days in the example at T+35 above.
			It is important to note that this value affects not just the
			publication of new DNSKEYs intended to be used as trust anchors, but
			also the length of time required to publish a DNSKEY with the revoke
			bit set. Both of these publication timing requirements are affected
			by the attacks described in this document.
	7. IANA Considerations		7. IANA Considerations
	This document contains no IANA considerations.		This document contains no IANA considerations.
	8. Operational Considerations		8. Operational Considerations
	A companion document to RFC5011 was expected to be published that		A companion document to RFC5011 was expected to be published that
	describes the best operational practice considerations from the		describes the best operational practice considerations from the
	perspective of a zone publisher and Trust Anchor Publisher. However,		perspective of a zone publisher and Trust Anchor Publisher. However,
	this companion document was never written. The authors of this		this companion document has yet to be published. The authors of this
	document hope that it will at some point in the future, as RFC5011		document hope that it will at some point in the future, as RFC5011
	timing can be tricky as we have shown. This document is intended		timing can be tricky as we have shown and we do not suggest "good
	only to fill a single operational void that results in security		operational practice" that might be associated with a BCP on the
	ramifications (specifically a denial of service attack against an		subject. This document is intended only to fill a single operational
	RFC5011 Validator). This document does not attempt to document any		void that results in security ramifications (specifically a denial of
	other missing operational guidance for zone publishers.		service attack against an RFC5011 Validator). This document does not
			attempt to document any other missing operational guidance for zone
			publishers.
	9. Security Considerations		9. Security Considerations
	This document, is solely about the security considerations with		This document, is solely about the security considerations with
	respect to the Trust Anchor Publisher of RFC5011 trust anchors /		respect to the Trust Anchor Publisher of RFC5011 trust anchors /
	keys. Thus the entire document is a discussion of Security		keys. Thus the entire document is a discussion of Security
	Considerations		Considerations when rolling DNSKEYs using the RFC5011 process.
	10. Acknowledgements		10. Acknowledgements
	The authors would like to especially thank to Michael StJohns for his		The authors would like to especially thank to Michael StJohns for his
	help and advice. We would also like to thank Bob Harold, Shane Kerr,		help and advice and the care and thought he put into RFC5011 itself.
	Matthijs Mekking, Duane Wessels, Petr ?pa?ek, and everyone else who		We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking,
			Duane Wessels, Petr Petr Spacek, and the dnsop working group who have
	assisted with this document.		assisted with this document.
	11. Normative References		11. Normative References
	[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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
			[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
			Rose, "DNS Security Introduction and Requirements",
			RFC 4033, DOI 10.17487/RFC4033, March 2005,
			<http://www.rfc-editor.org/info/rfc4033>.
	[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>.
	Appendix A. Changes / Author Notes.		[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
			Terminology", RFC 7719, DOI 10.17487/RFC7719, December
			2015, <http://www.rfc-editor.org/info/rfc7719>.
	From -00 to -02:		Appendix A. Real World Example: The 2017 Root KSK Key Roll
			In 2017, ICANN expects to (or has, depending on when you're reading
			this) roll the key signing key (KSK) for the root zone. The relevant
			parameters associated with the root zone at the time of this writing
			is as follows:
			addHoldDownTime: 30 days
			Old DNSKEY RRSIG Signature Validity: 21 days
			Old DNSKEY TTL: 2 days
			Thus, sticking this information into the equation in
			Section Section 6 yields (in days):
			waitTime = addHoldDownTime
			+ (DNSKEY RRSIG Signature Validity)
			+ MAX(MIN((DNSKEY RRSIG Signature Validity) / 2,
			MAX(original TTL of K_old DNSKEY RRSet) / 2,
			15 days),
			1 hour)
			+ 2 * MAX(TTL of all records)
			waitTime = 30
			+ (21)
			+ MAX(MIN((21) / 2,
			MAX(2 / 2,
			15 days)),
			1 hour)
			+ 2 * MAX(2)
			waitTime = 30 + 21 + MAX(MIN(11.5, MAX( 1, 15)), 1 hour) + 4
			waitTime = 30 + 21 + 11.5 + 4
			waitTime = 66.5 days
			Thus, ICANN should wait 66.5 days before switching to the newly
			published KSK and before removing the old revoked key once it is
			published as revoked. ICANN's current plans are to wait 70 days
			before using the new KEY and 69 days before removing the old, revoked
			key. Thus, their current rollover plans are sufficiently secure from
			the attack discussed in this memo.
			Appendix B. Changes / Author Notes.
			From Individual-00 to DNSOP-00:
			o Filename change.
			From -00 to -01:
			o Added Revocation processing (including "Timing Associated with
			Revocation")
			o Added real world example.
			o Fixed some typoes and missing references.
			From Ind-00 to -02:
	Additional background and clarifications in abstract.		Additional background and clarifications in abstract.
	Better separation in attack description between attacked and non-		Better separation in attack description between attacked and non-
	attacked resolvers.		attacked resolvers.
	Some language cleanup.		Some language cleanup.
	Clarified that this is maths ( and math is hard, let's go		Clarified that this is maths ( and math is hard, let's go
	shopping!)		shopping!)
	skipping to change at page 9, line 25 ¶		skipping to change at page 11, line 51 ¶
	Changed min wait time math to include TTL value as well		Changed min wait time math to include TTL value as well
	From -03 to -04:		From -03 to -04:
	Fixed the waitTime equation to handle the difference between the		Fixed the waitTime equation to handle the difference between the
	usage of the expiration time and the Active Refresh time.		usage of the expiration time and the Active Refresh time.
	More clarification text and text changes proposed by Petr Spacek		More clarification text and text changes proposed by Petr Spacek
			From hardaker-04 to ietf-00:
			Just rebranding.
			From ietf-00 to ietf-01:
			Added discussion surrounding revocation everywhere
			Fixed the text about the formula
			Another complete re-read for word-smithing
	Authors' Addresses		Authors' Addresses
	Wes Hardaker		Wes Hardaker
	Parsons, Inc.		USC/ISI
	P.O. Box 382		P.O. Box 382
	Davis, CA 95617		Davis, CA 95617
	US		US
	Email: ietf@hardakers.net		Email: ietf@hardakers.net
	Warren Kumari		Warren Kumari
	Google		Google
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, CA 94043		Mountain View, CA 94043
End of changes. 46 change blocks.
	154 lines changed or deleted		286 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/