< draft-ietf-dnsop-rfc5011-security-considerations-08.txt		draft-ietf-dnsop-rfc5011-security-considerations-09.txt >
	dnsop W. Hardaker		dnsop W. Hardaker
	Internet-Draft USC/ISI		Internet-Draft USC/ISI
	Updates: 7583 (if approved) W. Kumari		Updates: 7583 (if approved) W. Kumari
	Intended status: Standards Track Google		Intended status: Standards Track Google
	Expires: June 2, 2018 November 29, 2017		Expires: June 10, 2018 December 07, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-ietf-dnsop-rfc5011-security-considerations-08		draft-ietf-dnsop-rfc5011-security-considerations-09
	Abstract		Abstract
	This document extends the RFC5011 rollover strategy with timing		This document extends the RFC5011 rollover strategy with timing
	advice that must be followed in order to maintain security.		advice that must be followed by the publisher in order to maintain
	Specifically, this document describes the math behind the minimum		security. Specifically, this document describes the math behind the
	time-length that a DNS zone publisher must wait before signing		minimum time-length that a DNS zone publisher must wait before
	exclusively with recently added DNSKEYs. It contains much math and		signing exclusively with recently added DNSKEYs. This document also
	complicated equations, but the summary is that the key rollover /		describes the minimum time-length that a DNS zone publisher must wait
	revocation time is much longer than intuition would suggest. If you		after publishing a revoked DNSKEY before assuming that all active
	are not both publishing a DNSSEC DNSKEY, and using RFC5011 to		RFC5011 resolvers should have seen the revocation-marked key and
	advertise this DNSKEY as a new Secure Entry Point key for use as a		removed it from their list of trust anchors.
	trust anchor, you probably don't need to read this document.
	This document also describes the minimum time-length that a DNS zone		This document contains much math and complicated equations, but the
	publisher must wait after publishing a revoked DNSKEY before assuming		summary is that the key rollover / revocation time is much longer
	that all active RFC5011 resolvers should have seen the revocation-		than intuition would suggest. If you are not both publishing a
	marked key and removed it from their list of trust anchors.		DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new
			Secure Entry Point key for use as a trust anchor, you probably don't
			need to read this document.
	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 June 2, 2018.		This Internet-Draft will expire on June 10, 2018.
	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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Document History and Motivation . . . . . . . . . . . . . 3		1.1. Document History and Motivation . . . . . . . . . . . . . 3
	1.2. Safely Rolling the Root Zone's KSK in 2017/2018 . . . . . 3		1.2. Safely Rolling the Root Zone's KSK in 2017/2018 . . . . . 3
	1.3. Requirements notation . . . . . . . . . . . . . . . . . . 4		1.3. Requirements notation . . . . . . . . . . . . . . . . . . 4
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Timing Associated with RFC5011 Processing . . . . . . . . . . 5		4. Timing Associated with RFC5011 Processing . . . . . . . . . . 5
	4.1. Timing Associated with Publication . . . . . . . . . . . 5		4.1. Timing Associated with Publication . . . . . . . . . . . 5
	4.2. Timing Associated with Revocation . . . . . . . . . . . . 6		4.2. Timing Associated with Revocation . . . . . . . . . . . . 5
	5. Denial of Service Attack Walkthrough . . . . . . . . . . . . 6		5. Denial of Service Attack Walkthrough . . . . . . . . . . . . 6
	5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6		5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6
	5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 7		5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 7
	6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 9		6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8
	6.1. Equation Components . . . . . . . . . . . . . . . . . . . 9		6.1. Equation Components . . . . . . . . . . . . . . . . . . . 8
	6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 9		6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 9
	6.1.2. sigExpirationTimeRemaining . . . . . . . . . . . . . 9		6.1.2. lastSigExpirationTime . . . . . . . . . . . . . . . . 9
	6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 9		6.1.3. sigExpirationTime . . . . . . . . . . . . . . . . . . 9
	6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9		6.1.4. sigExpirationTimeRemaining . . . . . . . . . . . . . 9
	6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 10		6.1.5. sigExpirationTimeRemaining . . . . . . . . . . . . . 9
			6.1.6. activeRefresh . . . . . . . . . . . . . . . . . . . . 9
			6.1.7. activeRefreshOffset . . . . . . . . . . . . . . . . . 10
			6.1.8. safetyMargin . . . . . . . . . . . . . . . . . . . . 10
	6.2. Timing Requirements For Adding a New KSK . . . . . . . . 11		6.2. Timing Requirements For Adding a New KSK . . . . . . . . 11
	6.2.1. Wait Timer Based Calculation . . . . . . . . . . . . 11		6.2.1. Wait Timer Based Calculation . . . . . . . . . . . . 11
	6.2.2. Wall-Clock Based Calculation . . . . . . . . . . . . 12		6.2.2. Wall-Clock Based Calculation . . . . . . . . . . . . 12
	6.2.3. Timing Constraint Summary . . . . . . . . . . . . . . 12		6.2.3. Timing Constraint Summary . . . . . . . . . . . . . . 13
	6.2.4. Additional Considerations for RFC7583 . . . . . . . . 13		6.2.4. Additional Considerations for RFC7583 . . . . . . . . 13
	6.2.5. Example Scenario Calculations . . . . . . . . . . . . 13		6.2.5. Example Scenario Calculations . . . . . . . . . . . . 13
	6.3. Timing Requirements For Revoking an Old KSK . . . . . . . 13		6.3. Timing Requirements For Revoking an Old KSK . . . . . . . 14
	6.3.1. Wait Timer Based Calculation . . . . . . . . . . . . 14		6.3.1. Wait Timer Based Calculation . . . . . . . . . . . . 14
	6.3.2. Wall-Clock Based Calculation . . . . . . . . . . . . 14		6.3.2. Wall-Clock Based Calculation . . . . . . . . . . . . 14
	6.3.3. Additional Considerations for RFC7583 . . . . . . . . 15		6.3.3. Additional Considerations for RFC7583 . . . . . . . . 15
	6.3.4. Example Scenario Calculations . . . . . . . . . . . . 15		6.3.4. Example Scenario Calculations . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Operational Considerations . . . . . . . . . . . . . . . . . 15		8. Operational Considerations . . . . . . . . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	11. Normative References . . . . . . . . . . . . . . . . . . . . 16		11. Normative References . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 17		Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	[RFC5011] defines a mechanism by which DNSSEC validators can update		[RFC5011] defines a mechanism by which DNSSEC validators can update
	their list of trust anchors when they've seen a new key published in		their list of trust anchors when they've seen a new key published in
	a zone or revoke a properly marked key from a trust anchor list.		a zone or revoke a properly marked key from a trust anchor list.
	However, RFC5011 [intentionally] provides no guidance to the		However, RFC5011 [intentionally] provides no guidance to the
	publishers of DNSKEYs about how long they must wait before switching		publishers of DNSKEYs about how long they must wait before switching
	to exclusively using recently published keys for signing records, or		to exclusively using recently published keys for signing records, or
	how long they must wait before ceasing publication of a revoked key.		how long they must wait before ceasing publication of a revoked key.
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 38 ¶
	is written to provide timing guidance solely to a Validating		is written to provide timing guidance solely to a Validating
	Resolver's point of view).		Resolver's point of view).
	1.1. Document History and Motivation		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 signing a zone exclusively with a new KSK		they must wait before signing a zone exclusively with a new KSK
	[RFC4033] that was being introduced according to the 5011 process.		[RFC4033] that was being introduced according to the 5011 process.
	All 5 experts answered with an insecure value, and we determined that		All 5 experts answered with an insecure value, and we determined that
	this lack of operational guidance might cause security concerns in		this lack of mathematical understanding might cause security concerns
	deployment and wrote this companion document to RFC5011. We hope		in deployment. We hope that this companion document to RFC5011 will
	that this document will rectify this understanding and provide better		rectify this understanding and provide better guidance to zone
	guidance to zone publishers that wish to make use of the RFC5011		publishers that wish to make use of the RFC5011 rollover process.
	rollover process.
	1.2. Safely Rolling the Root Zone's KSK in 2017/2018		1.2. Safely Rolling the Root Zone's KSK in 2017/2018
	One important note about ICANN's (currently in process) 2017/2018 KSK		One important note about ICANN's (currently in process) 2017/2018 KSK
	rollover plan for the root zone: the timing values chosen for rolling		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		the KSK in the root zone appear completely safe, and are not affected
	by the timing concerns introduced by this draft		by the timing concerns introduced by this draft
	1.3. Requirements notation		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 RFC5011 Resolver		The RFC5011 process describes a process by which a RFC5011 Resolver
	may accept a newly published KSK as a trust anchor for validating		may accept a newly published KSK as a trust anchor for validating
	future DNSSEC signed records. It also describes the process for		future DNSSEC signed records. It also describes the process for
	publicly revoking a published KSK. This document augments that		publicly revoking a published KSK. This document augments that
	information with additional constraints, from the DNSKEY publication		information with additional constraints, from the SEP publisher's
	and revocation's points of view. Note that this document does not		points of view. Note that this document does not define any other
	define any other operational guidance or recommendations about the		operational guidance or recommendations about the RFC5011 process and
	RFC5011 process and restricts itself to solely the security and		restricts itself to solely the security and operational ramifications
	operational ramifications of switching to exclusively using recently		of switching to exclusively using recently added keys or removing
	added keys or removing a revoked keys too soon.		revoked keys too soon.
	Failure of a DNSKEY publisher to follow the minimum recommendations		Failure of a DNSKEY publisher to follow the minimum recommendations
	associated with this draft can result in potential denial-of-service		associated with this draft can result in potential denial-of-service
	attack opportunities against validating resolvers. Failure of a		attack opportunities against validating resolvers. Failure of a
	DNSKEY publisher to publish a revoked key for a long enough period of		DNSKEY publisher to publish a revoked key for a long enough period of
	time may result in RFC5011 Resolvers leaving that key in their trust		time may result in RFC5011 Resolvers leaving that key in their trust
	anchor storage beyond the key's expected lifetime.		anchor storage beyond the key's expected lifetime.
	3. Terminology		3. Terminology
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 49 ¶
	following the RFC5011 process.		following the RFC5011 process.
	RFC5011 Resolver A DNSSEC Resolver that is using the RFC5011		RFC5011 Resolver A DNSSEC Resolver that is using the RFC5011
	processes to track and update trust anchors.		processes to track and update trust anchors.
	Attacker An entity intent on foiling the RFC5011 Resolver's ability		Attacker An entity intent on foiling the RFC5011 Resolver's ability
	to successfully adopt the Zone Signer's new DNSKEY as a new trust		to successfully adopt the Zone Signer's new DNSKEY as a new trust
	anchor or to prevent the RFC5011 Resolver from removing an old		anchor or to prevent the RFC5011 Resolver from removing an old
	DNSKEY from its list of trust anchors.		DNSKEY from its list of trust anchors.
	lastSigExpirationTime The latest value of any RRSIG Signature
	Expiration field (which is a date and time) that has signed the
	previous DNSKEY RRset before a new DNSKEY is introduced to a
	publish DNSKEY RRset, or the DNSKEY RRset of a DNSKEY that is to
	be revoked. Note that for organizations pre-creating signatures
	this time may be fairly far in the future unless they can be
	significantly assured that none of their pre-generated signatures
	can be replayed at a later date.
	sigExpirationTime The amount of time between the DNSKEY RRSIG's		sigExpirationTime The amount of time between the DNSKEY RRSIG's
	Signature Inception field and the Signature Expiration field.		Signature Inception field and the Signature Expiration field.
	sigExpirationTimeRemaining The amount of time remaining before
	latestSigExpirationTime is reached.
	Also see Section 2 of [RFC4033] and [RFC7719] for additional		Also see Section 2 of [RFC4033] and [RFC7719] for additional
	terminology.		terminology.
	4. Timing Associated with RFC5011 Processing		4. Timing Associated with RFC5011 Processing
	These sections define a high-level overview of [RFC5011] processing.		These sections define a high-level overview of [RFC5011] processing.
	These steps are not sufficient for proper RFC5011 implementation, but		These steps are not sufficient for proper RFC5011 implementation, but
	provide enough background for the reader to follow the discussion in		provide enough background for the reader to follow the discussion in
	this document. Readers need to fully understand [RFC5011] as well to		this document. Readers need to fully understand [RFC5011] as well to
	fully comprehend the content and importance of this document.		fully comprehend the content and importance of this document.
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 19 ¶
	belief, which results in a revoked DNSKEY potentially remaining as a		belief, which results in a revoked DNSKEY potentially remaining as a
	trust anchor in a RFC5011 Resolver long past its expected usage.		trust anchor in a RFC5011 Resolver long past its expected usage.
	5. Denial of Service Attack Walkthrough		5. Denial of Service Attack Walkthrough
	This section serves as an illustrative example of the problem being		This section serves as an illustrative example of the problem being
	discussed in this document. Note that in order to keep the example		discussed in this document. Note that in order to keep the example
	simple enough to understand, some simplifications were made (such as		simple enough to understand, some simplifications were made (such as
	by not creating a set of pre-signed RRSIGs and by not using values		by not creating a set of pre-signed RRSIGs and by not using values
	that result in the addHoldDownTime not being evenly divisible by the		that result in the addHoldDownTime not being evenly divisible by the
	activeRefresh value); the mathematical formulas in Section 6,		activeRefresh value); the mathematical formulas in Section 6 are,
	however, are complete.		however, complete.
	If an attacker is able to provide a RFC5011 Resolver with past		If an attacker is able to provide a RFC5011 Resolver with past
	responses, such as when it is in-path or able to perform any number		responses, such as when it is in-path or able to perform any number
	of cache poisoning attacks, the attacker may be able to leave		of cache poisoning attacks, the attacker may be able to leave
	compliant RFC5011 Resolvers without an appropriate DNSKEY trust		compliant RFC5011 Resolvers without an appropriate DNSKEY trust
	anchor. This scenario will remain until an administrator manually		anchor. This scenario will remain until an administrator manually
	fixes the situation.		fixes the situation.
	The time-line below illustrates this situation.		The time-line below illustrates an example of 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
	sigExpirationTime 10 days		sigExpirationTime 10 days
	Zone resigned every 1 day		Zone resigned every 1 day
	Given these settings, the sequence of events in Section 5.1.1 depicts		Given these settings, the sequence of events in Section 5.1.1 depicts
	how a SEP Publisher that waits for only the RFC5011 hold time timer		how a SEP Publisher that waits for only the RFC5011 hold time timer
	length of 30 days subjects its users to a potential Denial of Service		length of 30 days subjects its users to a potential Denial of Service
	attack. The timing schedule listed below is based on a SEP Publisher		attack. The timing schedule listed below is based on a SEP Publisher
	publishing a new Key Signing Key (KSK), with the intent that it will		publishing a new Key Signing Key (KSK), with the intent that it will
	later be used as a trust anchor. We label this publication time as		later be used as a trust anchor. We label this publication time as
	"T+0". All numbers in this sequence refer to days before and after		"T+0". All numbers in this sequence refer to days before and after
	this initial publication event. Thus, T-1 is the day before the		this initial publication event. Thus, T-1 is the day before the
	skipping to change at page 8, line 5 ¶		skipping to change at page 7, line 41 ¶
	world scenario there will likely be a further delay between the		world scenario there will likely be a further delay between the
	point where the Zone Signer publishes a new RRSIG and the RFC5011		point where the Zone Signer publishes a new RRSIG and the RFC5011
	Resolver notices its publication; though not shown in this		Resolver notices its publication; though not shown in this
	example, this delay is accounted for in the equation in Section 6		example, this delay is accounted for in the equation in Section 6
	below]		below]
	T+5 The RFC5011 Resolver queries for the zone's keyset per the		T+5 The RFC5011 Resolver queries for the zone's keyset per the
	RFC5011 Active Refresh schedule, discussed in Section 2.3 of		RFC5011 Active Refresh schedule, discussed in Section 2.3 of
	RFC5011. Instead of receiving the intended published keyset, the		RFC5011. Instead of receiving the intended published keyset, the
	Attacker successfully replays the keyset and associated signatures		Attacker successfully replays the keyset and associated signatures
	recorded at T-1. Because the signature lifetime is 10 days (in		recorded at T-1 to the victim RFC5011 Resolver. Because the
	this example), the replayed signature and keyset is accepted as		signature lifetime is 10 days (in this example), the replayed
	valid (being only 6 days old, which is less than		signature and keyset is accepted as valid (being only 6 days old,
	sigExpirationTime) and the RFC5011 Resolver cancels the (30-day)		which is less than sigExpirationTime) and the RFC5011 Resolver
	hold-down timer for K_new, per the RFC5011 algorithm.		cancels the (30-day) hold-down timer for K_new, per the RFC5011
			algorithm.
	T+10 The RFC5011 Resolver queries for the zone's keyset and		T+10 The RFC5011 Resolver queries for the zone's keyset and
	discovers a signed keyset that includes K_new (again), and is		discovers a signed keyset that includes K_new (again), and is
	signed by K_old. Note: the attacker is unable to replay the		signed by K_old. Note: the attacker is unable to replay the
	records cached at T-1, because they have now expired. Thus at		records cached at T-1, because the signatures have now expired.
	T+10, the RFC5011 Resolver starts (anew) the hold-timer for K_new.
			Thus at T+10, the RFC5011 Resolver starts (anew) the hold-timer
			for K_new.
	T+11 through T+29 The RFC5011 Resolver continues checking the zone's		T+11 through T+29 The RFC5011 Resolver continues checking the zone's
	key set at the prescribed regular intervals. During this period,		key set at the prescribed regular intervals. During this period,
	the attacker can no longer replay traffic to their benefit.		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 Resolver not under attack that had		hold-down timer of a RFC5011 Resolver 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 Resolver is		However, the hold-down timer of our attacked RFC5011 Resolver is
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 4 ¶
	apex will be deemed invalid by DNSSEC.		apex will be deemed invalid by DNSSEC.
	6. Minimum RFC5011 Timing Requirements		6. Minimum RFC5011 Timing Requirements
	This section defines the minimum timing requirements for making		This section defines the minimum timing requirements for making
	exclusive use of newly added DNSKEYs and timing requirements for		exclusive use of newly added DNSKEYs and timing requirements for
	ceasing the publication of DNSKEYs to be revoked. First, we define		ceasing the publication of DNSKEYs to be revoked. First, we define
	the term components used in both equations in Section 6.1.		the term components used in both equations in Section 6.1.
	6.1. Equation Components		6.1. Equation Components
	6.1.1. addHoldDownTime		6.1.1. addHoldDownTime
	The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as:		The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as:
	The add hold-down time is 30 days or the expiration time of the		The add hold-down time is 30 days or the expiration time of the
	original TTL of the first trust point DNSKEY RRSet that contained		original TTL of the first trust point DNSKEY RRSet that contained
	the new key, whichever is greater. This ensures that at least		the new key, whichever is greater. This ensures that at least
	two validated DNSKEY RRSets that contain the new key MUST be seen		two validated DNSKEY RRSets that contain the new key MUST be seen
	by the resolver prior to the key's acceptance.		by the resolver prior to the key's acceptance.
	6.1.2. sigExpirationTimeRemaining		6.1.2. lastSigExpirationTime
			The latest value (i.e. the future most date and time) of any RRSig
			Signature Expiration field covering any DNSKEY RRSet containing only
			the old trust anchor(s) that are being superseded. Note that for
			organizations pre-creating signatures this time may be fairly far in
			the future unless they can be significantly assured that none of
			their pre-generated signatures can be replayed at a later date.
			6.1.3. sigExpirationTime
			The amount of time between the DNSKEY RRSIG's Signature Inception
			field and the Signature Expiration field.
			6.1.4. sigExpirationTimeRemaining
			The amount of time remaining before lastSigExpirationTime is reached.
			6.1.5. sigExpirationTimeRemaining
	sigExpirationTimeRemaining is defined in Section 3.		sigExpirationTimeRemaining is defined in Section 3.
	6.1.3. activeRefresh		6.1.6. activeRefresh
	activeRefresh time is defined by RFC5011 by		activeRefresh time is defined by RFC5011 by
	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.
	This translates to:		This translates to:
	activeRefresh = MAX(1 hour,		activeRefresh = MAX(1 hour,
	MIN(sigExpirationTime / 2,		MIN(sigExpirationTime / 2,
	MAX(TTL of K_old DNSKEY RRSet) / 2,		MAX(TTL of K_old DNSKEY RRSet) / 2,
	15 days)		15 days)
	)		)
	6.1.4. activeRefreshOffset		6.1.7. activeRefreshOffset
	The activeRefreshOffset term must be added for situations where the		The activeRefreshOffset term must be added for situations where the
	activeRefresh value is not a factor of the addHoldDownTime.		activeRefresh value is not a factor of the addHoldDownTime.
	Specifically, activeRefreshOffset will be "addHoldDownTime %		Specifically, activeRefreshOffset will be "addHoldDownTime %
	activeRefresh", where % is the mathematical mod operator (calculating		activeRefresh", where % is the mathematical mod operator (calculating
	the remainder in a division problem). This will frequently be zero,		the remainder in a division problem). This will frequently be zero,
	but could be nearly as large as activeRefresh itself. For		but could be nearly as large as activeRefresh itself. For
	simplicity, setting the activeRefreshOffset to the activeRefresh		simplicity, setting the activeRefreshOffset to the activeRefresh
	value itself is always safe.		value itself is always safe.
	6.1.5. safetyMargin		6.1.8. safetyMargin
	The safetyMargin is an extra period of time to account for caching,		The safetyMargin is an extra period of time to account for caching,
	network delays, dropped packets, and other operational concerns		network delays, dropped packets, and other operational concerns
	otherwise beyond the scope of this document. The value operators		otherwise beyond the scope of this document. The value operators
	should chose is highly dependent on the deployment siptuation		should chose is highly dependent on the deployment situation
	associated with their zone. Note that no value of a safetyMargin can		associated with their zone. Note that no value of a safetyMargin can
	protect against resolvers that are "down". None the less, we do		protect against resolvers that are "down". None the less, we do
	offer the following as one method considering reasonable values to		offer the following as one method considering reasonable values to
	select from.		select from.
	The following list of variables need to be considered when selecting		The following list of variables need to be considered when selecting
	an appropriate safetyMargin value:		an appropriate safetyMargin value:
	successRate: A likely success rate for client queries and retries		successRate: A likely success rate for client queries and retries
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 49 ¶
	Note that RFC5011 defines retryTime as:		Note that RFC5011 defines retryTime as:
	If the query fails, the resolver MUST repeat the query until		If the query fails, the resolver MUST repeat the query until
	satisfied no more often than once an hour and no less often		satisfied no more often than once an hour and no less often
	than the lesser of 1 day, 10% of the original TTL, or 10% of		than the lesser of 1 day, 10% of the original TTL, or 10% of
	the original expiration interval. That is,		the original expiration interval. That is,
	retryTime = MAX (1 hour, MIN (1 day, .1 * origTTL,		retryTime = MAX (1 hour, MIN (1 day, .1 * origTTL,
	.1 * expireInterval)).		.1 * expireInterval)).
	With these values selected and the definition of retryTime from		With the successRate and numResolvers values selected and the
	RFC5011, one method for determining how many retryTime intervals to		definition of retryTime from RFC5011, one method for determining how
	wait in order to reduce the set of uncompleted servers to 0 assuming		many retryTime intervals to wait in order to reduce the set of
	normal probability is thus:		uncompleted servers to 0 assuming normal probability is thus:
	x = (1/(1 - successRate))		x = (1/(1 - successRate))
	retryCountWait = Log_base_x(numResolvers)		retryCountWait = Log_base_x(numResolvers)
	To reduce the need for readers to pull out a scientific calculator,		To reduce the need for readers to pull out a scientific calculator,
	we offer the following lookup table based on successRate and		we offer the following lookup table based on successRate and
	numResolvers:		numResolvers:
	retryCountWait lookup table		retryCountWait lookup table
	---------------------------		---------------------------
	Number of client RFC5011 Resolvers (numResolvers)		Number of client RFC5011 Resolvers (numResolvers)
			-------------------------------------------------
	10,000 100,000 1,000,000 10,000,000 100,000,000		10,000 100,000 1,000,000 10,000,000 100,000,000
	0.01 917 1146 1375 1604 1833		0.01 917 1146 1375 1604 1833
	Probability 0.05 180 225 270 315 360		Probability 0.05 180 225 270 315 360
	of Success 0.10 88 110 132 153 175		of Success 0.10 88 110 132 153 175
	Per Retry 0.15 57 71 86 100 114		Per Retry 0.15 57 71 86 100 114
	Interval 0.25 33 41 49 57 65		Interval 0.25 33 41 49 57 65
	(successRate) 0.50 14 17 20 24 27		(successRate) 0.50 14 17 20 24 27
	0.90 4 5 6 7 8		0.90 4 5 6 7 8
	0.95 4 4 5 6 7		0.95 4 4 5 6 7
	0.99 2 3 3 4 4		0.99 2 3 3 4 4
	0.999 2 2 2 3 3		0.999 2 2 2 3 3
	Finally, a suggested value of safetyMargin can then be this		Finally, a suggested value of safetyMargin can then be this
	retryCountWait number multiplied by the retryTime from RFC5011:		retryCountWait number multiplied by the retryTime from RFC5011:
	safetyMargin = retryCountWait * retryTime		safetyMargin = retryCountWait * retryTime
	6.2. Timing Requirements For Adding a New KSK		6.2. Timing Requirements For Adding a New KSK
	This section defines a method for calculating the amount of time to		Section 6.2.1 defines a method for calculating the amount of time to
	wait until it is safe to start signing exclusively with a new key		wait until it is safe to start signing exclusively with a new DNSKEY
	Section 6.2.1 (especially useful for writing code involving sleep		(especially useful for writing code involving sleep based timers),
	based timers), and an a method for calculating a wall-clock value		and Section 6.2.2 defines a method for calculating a wall-clock value
	after which it is safe to start signing exclusively with a new key		after which it is safe to start signing exclusively with a new DNSKEY
	Section 6.2.2 (especially useful for writing code based on clock-		(especially useful for writing code based on clock-based event
	based event triggers).		triggers).
	6.2.1. Wait Timer Based Calculation		6.2.1. Wait Timer Based Calculation
	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 after publishing K_new		of time required for the Zone Signer to wait after publishing K_new
	but before exclusively using it and newer keys is:		but before exclusively using it and newer keys is:
	addWaitTime = addHoldDownTime		addWaitTime = addHoldDownTime
	+ sigExpirationTimeRemaining		+ sigExpirationTimeRemaining
	+ activeRefresh		+ activeRefresh
	+ activeRefreshOffset		+ activeRefreshOffset
	+ safetyMargin		+ safetyMargin
	6.2.1.1. Fully expanded equation		6.2.1.1. Fully expanded equation
	The full expanded equation is:		Given the equation components defined in Section 6.1, the full
			expanded equation is:
	addWaitTime = addHoldDownTime		addWaitTime = addHoldDownTime
	+ sigExpirationTimeRemaining		+ sigExpirationTimeRemaining
	+ 2 * MAX(1 hour,		+ MAX(1 hour,
	MIN(sigExpirationTime / 2,		MIN(sigExpirationTime / 2,
	MAX(TTL of K_old DNSKEY RRSet) / 2,		MAX(TTL of K_old DNSKEY RRSet) / 2,
	15 days)		15 days)
	)		)
	+ (addHoldDownTime % activeRefresh)		+ (addHoldDownTime % activeRefresh)
	+ MAX(1.5 hours, 2 * MAX(TTL of all records))		+ MAX(1.5 hours, 2 * MAX(TTL of all records))
	+ safetyMargin		+ safetyMargin
	6.2.2. Wall-Clock Based Calculation		6.2.2. Wall-Clock Based Calculation
	The above equations are defined based upon how long to wait from a		The equations in Section 6.2.1 are defined based upon how long to
	particular moment in time. An alternative, but equivalent, method is		wait from a particular moment in time. An alternative, but
	to calculate the date and time before which it is unsafe to use a key		equivalent, method is to calculate the date and time before which it
	for signing. This calculation thus becomes:		is unsafe to use a key for signing. This calculation thus becomes:
	addWallClockTime = lastSigExpirationTime		addWallClockTime = lastSigExpirationTime
	+ addHoldDownTime		+ addHoldDownTime
	+ activeRefresh		+ activeRefresh
	+ activeRefreshOffset		+ activeRefreshOffset
	+ safetyMargin		+ safetyMargin
	where lastSigExpirationTime is the latest value of any		where lastSigExpirationTime is the latest value of any
	sigExpirationTime for which RRSIGs were created that could		sigExpirationTime for which RRSIGs were created that could
	potentially be replayed. Fully expanded, this becomes:		potentially be replayed. Fully expanded, this becomes:
	addWallClockTime = lastSigExpirationTime		addWallClockTime = lastSigExpirationTime
	+ addHoldDownTime		+ addHoldDownTime
	+ 2 * MAX(1 hour,		+ 2 * MAX(1 hour,
	MIN(sigExpirationTime / 2,		MIN(sigExpirationTime / 2,
	MAX(TTL of K_old DNSKEY RRSet) / 2,		MAX(TTL of K_old DNSKEY RRSet) / 2,
	15 days)		15 days)
	)		)
	+ (addHoldDownTime % activeRefresh)		+ (addHoldDownTime % activeRefresh)
	+ MAX(1.5 hours, 2 * MAX(TTL of all records))		+ MAX(1.5 hours, 2 * MAX(TTL of all records))
	+ safetyMargin		+ safetyMargin
	6.2.3. Timing Constraint Summary		6.2.3. Timing Constraint Summary
	The important timing constraint introduced by this memo relates to		The important timing constraint introduced by this memo relates to
	the last point at which a RFC5011 Resolver may have received a		the last point at which a RFC5011 Resolver may have received a
	replayed original DNSKEY set, containing K_old and not K_new. The		replayed original DNSKEY set, containing K_old and not K_new. The
	next query of the RFC5011 validator at which K_new will be seen		next query of the RFC5011 validator at which K_new will be seen
	without the potential for a replay attack will occur after the		without the potential for a replay attack will occur after the old
	publication time plus sigExpirationTime. Thus, the latest time that		DNSKEY RRSIG's Signature Expriation Time. Thus, the latest time that
	a RFC5011 Validator may begin their hold down timer is an "Active		a RFC5011 Validator may begin their hold down timer is an "Active
	Refresh" period after the last point that an attacker can replay the		Refresh" period after the last point that an attacker can replay the
	K_old DNSKEY set. The worst case scenario of this attack is if the		K_old DNSKEY set. The worst case scenario of this attack is if the
	attacker can replay K_old just seconds before the (DNSKEY RRSIG		attacker can replay K_old just seconds before the (DNSKEY RRSIG
	Signature Validity) field of the last K_old only RRSIG.		Signature Validity) field of the last K_old only RRSIG.
	6.2.4. Additional Considerations for RFC7583		6.2.4. Additional Considerations for RFC7583
	Note: our notion of addWaitTime is called "Itrp" in Section 3.3.4.1		Note: our notion of addWaitTime is called "Itrp" in Section 3.3.4.1
	of [RFC7583]. The equation for Itrp in RFC7583 is insecure as it		of [RFC7583]. The equation for Itrp in RFC7583 is insecure as it
	does not include the sigExpirationTime listed above. The Itrp		does not include the sigExpirationTime listed above. The Itrp
	equation in RFC7583 also does not include the 2*TTL safety margin,		equation in RFC7583 also does not include the 2*TTL safety margin,
	though that is an operational consideration and not necessarily as		though that is an operational consideration.
	critical.
	6.2.5. Example Scenario Calculations		6.2.5. Example Scenario Calculations
	For the parameters listed in Section 5.1, the activeRefreshOffset is		For the parameters listed in Section 5.1, the activeRefreshOffset is
	0, since 30 days is evenly divisible by activeRefresh (1/2 day), and		0, since 30 days is evenly divisible by activeRefresh (1/2 day), and
	our resulting addWaitTime is:		our resulting addWaitTime is:
	addWaitTime = 30		addWaitTime = 30
	+ 10		+ 10
	+ 1 / 2		+ 1 / 2
	+ 2 * (1) (days)		+ 0 (days)
	addWaitTime = 42.5 (days)		addWaitTime = 42.5 (days)
	This addWaitTime of 42.5 days is 12.5 days longer than just the hold		This addWaitTime of 42.5 days is 12.5 days longer than just the hold
	down timer.		down timer, even with the needed safetyMargin value being left out
			(which we exclude due to the lack of necessary operational
			parameters).
	6.3. Timing Requirements For Revoking an Old KSK		6.3. Timing Requirements For Revoking an Old KSK
	This issue affects not just the publication of new DNSKEYs intended		This issue affects not just the publication of new DNSKEYs intended
	to be used as trust anchors, but also the length of time required to		to be used as trust anchors, but also the length of time required to
	continuously publish a DNSKEY with the revoke bit set.		continuously publish a DNSKEY with the revoke bit set.
	This section defines a method for calculating the amount of time		Section 6.2.1 defines a method for calculating the amount of time
	operators need to wait until it is safe to cease publishing a DNSKEY		operators need to wait until it is safe to cease publishing a DNSKEY
	Section 6.2.1 (especially useful for writing code involving sleep		(especially useful for writing code involving sleep based timers),
	based timers), and an a method for calculating a minimal wall-clock		and Section 6.2.2 defines a method for calculating a minimal wall-
	value after which it is safe to cease publishing a DNSKEY		clock value after which it is safe to cease publishing a DNSKEY
	Section 6.2.2 (especially useful for writing code based on clock-		(especially useful for writing code based on clock-based event
	based event triggers).		triggers).
	6.3.1. Wait Timer Based Calculation		6.3.1. Wait Timer Based Calculation
	Both of these publication timing requirements are affected by the		Both of these publication timing requirements are affected by the
	attacks described in this document, but with revocation the key is		attacks described in this document, but with revocation the key is
	revoked immediately and the addHoldDown timer does not apply. Thus		revoked immediately and the addHoldDown timer does not apply. Thus
	the minimum amount of time that a SEP Publisher must wait before		the minimum amount of time that a SEP Publisher must wait before
	removing a revoked key from publication is:		removing a revoked key from publication is:
	remWaitTime = sigExpirationTimeRemaining		remWaitTime = sigExpirationTimeRemaining
			+ activeRefresh
			+ safetyMargin
			remWaitTime = sigExpirationTimeRemaining
	+ MAX(1 hour,		+ MAX(1 hour,
	MIN((sigExpirationTime) / 2,		MIN((sigExpirationTime) / 2,
	MAX(TTL of K_old DNSKEY RRSet) / 2,		MAX(TTL of K_old DNSKEY RRSet) / 2,
	15 days),		15 days))
	1 hour)		+ safetyMargin
	+ 2 * MAX(TTL of all records)
	Note that the activeRefreshOffset time does not apply to this		Note that the activeRefreshOffset time does not apply to this
	equation.		equation.
	Note also that adding retryTime intervals to the remWaitTime may be		Note also that adding retryTime intervals to the remWaitTime may be
	wise, just as it was for addWaitTime in Section 6.		wise, just as it was for addWaitTime in Section 6.
	6.3.2. Wall-Clock Based Calculation		6.3.2. Wall-Clock Based Calculation
	Like before, the above equations are defined based upon how long to		Like before, the above equations are defined based upon how long to
	wait from a particular moment in time. An alternative, but		wait from a particular moment in time. An alternative, but
	equivalent, method is to calculate the date and time before which it		equivalent, method is to calculate the date and time before which it
	is unsafe to cease publishing a revoked key. This calculation thus		is unsafe to cease publishing a revoked key. This calculation thus
	becomes:		becomes:
	remWallClockTime = lastSigExpirationTime		remWallClockTime = lastSigExpirationTime
	+ activeRefresh		+ activeRefresh
	+ activeRefreshOffset		+ safetyMargin
			remWallClockTime = lastSigExpirationTime
			+ MAX(1 hour,
			MIN((sigExpirationTime) / 2,
			MAX(TTL of K_old DNSKEY RRSet) / 2,
			15 days))
	+ safetyMargin		+ safetyMargin
	where lastSigExpirationTime is the latest value of any		where lastSigExpirationTime is the latest value of any
	sigExpirationTime for which RRSIGs were created that could		sigExpirationTime for which RRSIGs were created that could
	potentially be replayed. Fully expanded, this becomes:		potentially be replayed. Fully expanded, this becomes:
	remWallClockTime = lastSigExpirationTime
	+ 2 * MAX(1 hour,
	MIN(sigExpirationTime / 2,
	MAX(TTL of K_old DNSKEY RRSet) / 2,
	15 days)
	)
	+ (addHoldDownTime % activeRefresh)
	+ MAX(1.5 hours, 2 * MAX(TTL of all records))
	6.3.3. Additional Considerations for RFC7583		6.3.3. Additional Considerations for RFC7583
	Note that our notion of remWaitTime is called "Irev" in		Note that our notion of remWaitTime is called "Irev" in
	Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is		Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is
	insecure as it does not include the sigExpirationTime listed above.		insecure as it does not include the sigExpirationTime listed above.
	The Irev equation in RFC7583 also does not include the 2*TTL safety		The Irev equation in RFC7583 also does not include a safety margin,
	margin, though that is an operational consideration and not		though that is an operational consideration.
	necessarily as critical.
	6.3.4. Example Scenario Calculations		6.3.4. Example Scenario Calculations
	For the parameters listed in Section 5.1, our example:		For the parameters listed in Section 5.1, our example:
	remwaitTime = 10		remwaitTime = 10
	+ 1 / 2		+ 1 / 2 (days)
	+ 2 * (1) (days)
	remwaitTime = 12.5 (days)		remwaitTime = 10.5 (days)
	Note that for the values in this example produce a length shorter		Note that for the values in this example produce a length shorter
	than the recommended 30 days in RFC5011's section 6.6, step 3. Other		than the recommended 30 days in RFC5011's section 6.6, step 3. Other
	values of sigExpirationTime and the original TTL of the K_old DNSKEY		values of sigExpirationTime and the original TTL of the K_old DNSKEY
	RRSet, however, can produce values longer than 30 days.		RRSet, however, can produce values longer than 30 days.
	Note that because revocation happens immediately, an attacker has a		Note that because revocation happens immediately, an attacker has a
	much harder job tricking a RFC5011 Resolver into leaving a trust		much harder job tricking a RFC5011 Resolver into leaving a trust
	anchor in place, as the attacker must successfully replay the old		anchor in place, as the attacker must successfully replay the old
	data for every query a RFC5011 Resolver sends, not just one.		data for every query a RFC5011 Resolver sends, not just one.
	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 PEP Publisher. However, this		perspective of a zone publisher and SEP Publisher. However, this
	companion document has yet to be published. The authors of 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, and a BCP is clearly		timing can be tricky as we have shown, and a BCP is clearly
	warranted. This document is intended only to fill a single		warranted. This document is intended only to fill a single
	operational void which, when left misunderstood, can result in		operational void which, when left misunderstood, can result in
	serious security ramifications. This document does not attempt to		serious security ramifications. This document does not attempt to
	document any other missing operational guidance for zone publishers.		document any other missing operational guidance for zone publishers.
	9. Security Considerations		9. Security Considerations
	skipping to change at page 16, line 23 ¶		skipping to change at page 16, line 40 ¶
	For simplicity, this document assumes that the SEP Publisher will use		For simplicity, this document assumes that the SEP Publisher will use
	a consistent RRSIG validity period. SEP Publishers that vary the		a consistent RRSIG validity period. SEP Publishers that vary the
	length of RRSIG validity periods will need to adjust the		length of RRSIG validity periods will need to adjust the
	sigExpirationTime value accordingly so that the equations in		sigExpirationTime value accordingly so that the equations in
	Section 6 and Section 6.3 use a value that coincides with the last		Section 6 and Section 6.3 use a value that coincides with the last
	time a replay of older RRSIGs will no longer succeed.		time a replay of older RRSIGs will no longer succeed.
	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 and the care and thought he put into RFC5011 itself.		help and advice and the care and thought he put into RFC5011 itself
			and his continued reviews and suggestions for this document. He also
			designed the suggested math behind the suggested safetyMargin values
			in Section 6.1.8.
	We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking,		We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking,
	Duane Wessels, Petr Petr Spacek, Ed Lewis, and the dnsop working		Duane Wessels, Petr Petr Spacek, Ed Lewis, and the dnsop working
	group who have assisted with this document.		group who have 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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997, <https://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 4033, DOI 10.17487/RFC4033, March 2005,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<http://www.rfc-editor.org/info/rfc4033>.		<https://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, <https://www.rfc-editor.org/info/rfc5011>.
	[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,		[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
	"DNSSEC Key Rollover Timing Considerations", RFC 7583,		"DNSSEC Key Rollover Timing Considerations", RFC 7583,
	DOI 10.17487/RFC7583, October 2015, <https://www.rfc-		DOI 10.17487/RFC7583, October 2015, <https://www.rfc-
	editor.org/info/rfc7583>.		editor.org/info/rfc7583>.
	[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", RFC 7719, DOI 10.17487/RFC7719, December		Terminology", RFC 7719, DOI 10.17487/RFC7719, December
	2015, <http://www.rfc-editor.org/info/rfc7719>.		2015, <https://www.rfc-editor.org/info/rfc7719>.
	Appendix A. Real World Example: The 2017 Root KSK Key Roll		Appendix A. Real World Example: The 2017 Root KSK Key Roll
	In 2017, ICANN expects to (or has, depending on when you're reading		In 2017 and 2018, ICANN expects to (or has, depending on when you're
	this) roll the key signing key (KSK) for the root zone. The relevant		reading this) roll the key signing key (KSK) for the root zone. The
	parameters associated with the root zone at the time of this writing		relevant parameters associated with the root zone at the time of this
	is as follows:		writing is as follows:
	addHoldDownTime: 30 days		addHoldDownTime: 30 days
	Old DNSKEY sigExpirationTime: 21 days		Old DNSKEY sigExpirationTime: 21 days
	Old DNSKEY TTL: 2 days		Old DNSKEY TTL: 2 days
	Thus, sticking this information into the equation in		Thus, sticking this information into the equation in
	Section Section 6 yields (in days):		Section Section 6 yields (in days from publication time):
	addWaitTime = 30		addWaitTime = 30
	+ (21)		+ 21
	+ MAX(MIN((21) / 2,		+ MAX(1 hour,
	MAX(2 / 2,		MIN(21 / 2, # activeRefresh
	15 days)),		MAX(2) / 2,
	1 hour)		15 days),
	+ 2 * MAX(2)		)
			+ 30 % activeRefresh
	addWaitTime = 30 + 21 + MAX(MIN(11.5, 1, 15)), 1 hour) + 4		addWaitTime = 30 + 21
			+ MAX(1 hour, MIN(11.5, 1, 15)))
			+ 30 % activeRefresh
	addWaitTime = 30 + 21 + 1 + 4		addWaitTime = 30 + 21 + 1 + 30%1
	addWaitTime = 56 days		addWaitTime = 30 + 21 + 1 + 0
	Note that we use a activeRefreshOffset of 0, since 30 days is evenly		addWaitTime = 52 days
	divisible by activeRefresh (1 day).
	Thus, ICANN should wait a minimum of 56 days before switching to the		Note that activeRefreshOffset ends up being 0, since 30 days is
			evenly divisible by activeRefresh (1 day).
			Also note that we exclude the safetyMargin value, which is calculated
			based on the expected client deployment size.
			Thus, ICANN must wait a minimum of 52 days before switching to the
	newly published KSK (and 26 days before removing the old revoked key		newly published KSK (and 26 days before removing the old revoked key
	once it is published as revoked). ICANN's current plans are to wait		once it is published as revoked). ICANN's current plans involve
	70 days before using the new KEY and 69 days before removing the old,		waiting over 3 months before using the new KEY and 69 days before
	revoked key. Thus, their current rollover plans are sufficiently		removing the old, revoked key. Thus, their current rollover plans
	secure from the attack discussed in this memo.		are sufficiently secure from the attack discussed in this memo.
	Authors' Addresses		Authors' Addresses
	Wes Hardaker		Wes Hardaker
	USC/ISI		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
End of changes. 63 change blocks.
	149 lines changed or deleted		176 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/