< draft-ietf-dnsop-rfc5011-security-considerations-03.txt		draft-ietf-dnsop-rfc5011-security-considerations-04.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: March 16, 2018 September 12, 2017		Expires: March 17, 2018 September 13, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-ietf-dnsop-rfc5011-security-considerations-03		draft-ietf-dnsop-rfc5011-security-considerations-04
	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 in order to maintain security.
	Specifically, this document describes the math behind the minimum		Specifically, this document describes the math behind the minimum
	time-length that a DNS zone publisher must wait before signing		time-length that a DNS zone publisher must wait before signing
	exclusively with recently added DNSKEYs. This document also		exclusively with recently added DNSKEYs. It contains much math and
	describes the minimum time-length that a DNS zone publisher must wait		complicated equations, but the summary is that the key rollover /
	after publishing a revoked DNSKEY before assuming that all active		revocation time is much longer than intuition would suggest. If you
	RFC5011 resolvers should have seen the revocation-marked key and		are not both publishing a DNSSEC trust anchor, and using RFC5011 to
	removed it from their list of trust anchors.		update that trust anchor, you probably don't need to read this
			document.
			This document also describes the minimum time-length that a DNS zone
			publisher must wait after publishing a revoked DNSKEY before assuming
			that all active RFC5011 resolvers should have seen the revocation-
			marked key and removed it from their list of trust anchors.
	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 March 16, 2018.		This Internet-Draft will expire on March 17, 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 3		1.3. Requirements notation . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Timing Associated with RFC5011 Processing . . . . . . . . . . 4		4. Timing Associated with RFC5011 Processing . . . . . . . . . . 4
	4.1. Timing Associated with Publication . . . . . . . . . . . 4		4.1. Timing Associated with Publication . . . . . . . . . . . 5
	4.2. Timing Associated with Revocation . . . . . . . . . . . . 5		4.2. Timing Associated with Revocation . . . . . . . . . . . . 5
	5. Denial of Service Attack Considerations . . . . . . . . . . . 5		5. Denial of Service Attack Considerations . . . . . . . . . . . 5
	5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 5		5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6
	5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6		5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6
	6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8		6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8
	6.1. Timing Requirements For Adding a New KSK . . . . . . . . 8		6.1. Timing Requirements For Adding a New KSK . . . . . . . . 8
	6.1.1. Example Results . . . . . . . . . . . . . . . . . . . 10		6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 8
	6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 10		6.1.2. sigExpirationTime . . . . . . . . . . . . . . . . . . 8
			6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 8
			6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9
			6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 9
			6.1.6. Fully expanded equation . . . . . . . . . . . . . . . 9
			6.1.7. Timing Constraint Summary . . . . . . . . . . . . . . 10
			6.1.8. Additional Considerations . . . . . . . . . . . . . . 10
			6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 11
	6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 11		6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Operational Considerations . . . . . . . . . . . . . . . . . 11		8. Operational Considerations . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 11		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	11. Normative References . . . . . . . . . . . . . . . . . . . . 12		11. Normative References . . . . . . . . . . . . . . . . . . . . 13
	Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 12		Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	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. However, RFC5011 [intentionally] provides no guidance to the		a zone. 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.
	Because of this lack of guidance, zone publishers may derive		Because of this lack of guidance, zone publishers may derive
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 37 ¶
	RFC5011 Validating Resolver A DNSSEC Validating Resolver that is		RFC5011 Validating Resolver A DNSSEC Validating Resolver that is
	using the RFC5011 processes to track and update trust anchors.		using the RFC5011 processes to track and update trust anchors.
	Sometimes referred to as a "RFC5011 Resolver"		Sometimes referred to as a "RFC5011 Resolver"
	Attacker An entity intent on foiling the RFC5011 Validator's ability		Attacker An entity intent on foiling the RFC5011 Validator'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 Validator from removing an old		anchor or to prevent the RFC5011 Validator from removing an old
	DNSKEY from its list of trust anchors.		DNSKEY from its list of trust anchors.
	SigExpirationTime The amount of time remaining before a RRSIG's		sigExpirationTime The amount of time remaining before a RRSIG's
	Signature Expiration time is reached. This will fundamentally be		Signature Expiration time is reached. This will fundamentally be
	the RRSIG's Signature Expiration time minus the RRSIG's Signature		the RRSIG's Signature Expiration time minus the RRSIG's Signature
	Inception time when the signature is created.		Inception time when the signature is created.
	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.
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 16 ¶
	manually fixes the situation.		manually fixes the situation.
	The time-line below illustrates this situation.		The time-line below 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
	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 Trust Anchor Publisher that waits for only the RFC5011 hold		how a Trust Anchor Publisher that waits for only the RFC5011 hold
	time timer length of 30 days subjects its users to a potential Denial		time timer length of 30 days subjects its users to a potential Denial
	of Service attack. The timing schedule listed below is based on a		of Service attack. The timing schedule listed below is based on a
	Trust Anchor Publisher publishing a new Key Signing Key (KSK), with		Trust Anchor Publisher publishing a new Key Signing Key (KSK), with
	the intent that it will later become a trust anchor. We label this		the intent that it will later become a trust anchor. We label this
	publication time as "T+0". All numbers in this sequence refer to		publication time as "T+0". All numbers in this sequence refer to
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 23 ¶
	this example, this delay is accounted for in the final solution		this example, this delay is accounted for in the final solution
	below]		below]
	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
	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. Because the signature lifetime is 10 days (in
	this example), the replayed signature and keyset is accepted as		this example), the replayed signature and keyset is accepted as
	valid (being only 6 days old, which is less than		valid (being only 6 days old, which is less than
	SigExpirationTime) and the RFC5011 Validator cancels the hold-down		sigExpirationTime) and the RFC5011 Validator cancels the hold-down
	timer for K_new, per the RFC5011 algorithm.		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 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 they have now expired. Thus at
	T+10, the RFC5011 Validator starts (anew) the hold-timer for		T+10, the RFC5011 Validator starts (anew) the hold-timer for
	K_new.		K_new.
	T+11 through T-29 The RFC5011 Validator continues checking the		T+11 through T+29 The RFC5011 Validator continues checking the
	zone's key set at the prescribed regular intervals. During this		zone's key set at the prescribed regular intervals. During this
	period, the attacker can no longer replay traffic to their		period, the attacker can no longer replay traffic to their
	benefit.		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.
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 28 ¶
	6. Minimum RFC5011 Timing Requirements		6. Minimum RFC5011 Timing Requirements
	6.1. Timing Requirements For Adding a New KSK		6.1. Timing Requirements For Adding a New KSK
	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
	+ SigExpirationTime		+ sigExpirationTime
	+ activeRefresh		+ activeRefresh
	+ activeRefreshOffset		+ activeRefreshOffset
	+ 2 * MAX(TTL of all records)		+ safetyMargin
	Where activeRefresh time is defined by RFC5011 by:		6.1.1. addHoldDownTime
			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
			original TTL of the first trust point DNSKEY RRSet that contained
			the new key, whichever is greater. This ensures that at least
			two validated DNSKEY RRSets that contain the new key MUST be seen
			by the resolver prior to the key's acceptance.
			6.1.2. sigExpirationTime
			sigExpirationTime is defined in Section 3.
			6.1.3. activeRefresh
			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 the following equation:		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
	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 "30 days". Specifically,		activeRefresh value is not a factor of "30 days". Specifically,
	activeRefreshOffset will be "(30 days) % activeRefresh", where % is		activeRefreshOffset will be "(30 days) % activeRefresh", where % is
	the mathematical mod operator (which calculates the remainder in a		the mathematical mod operator (which calculates the remainder in a
	division problem). This will frequently be zero, but could be nearly		division problem). This will frequently be zero, but could be nearly
	as large as activeRefresh itself. For simplicity, setting the		as large as activeRefresh itself. For simplicity, setting the
	activeRefreshOffset to the activeRefresh value itself is safe.		activeRefreshOffset to the activeRefresh value itself is safe.
			6.1.5. safetyMargin
			The safetyMargin is an extra period of time to account for caching,
			network delays, etc. A suggested operational value for this is 2 *
			MAX(TTL of all records)
			RFC5011 also discusses a retryTime value for failed queries. Our
			equation cannot take into account undeterministic failure situations,
			so it might be wise to extend the safetyMargin by some factor of
			retryTime, which is defined in RFC5011 as:
			retryTime = MAX (1 hour,
			MIN (1 day,
			.1 * TTL of K_old DNSKEY RRset,
			.1 * sigExpirationTime))
			6.1.6. Fully expanded equation
	The full expanded equation, with activeRefreshOffset set to		The full expanded equation, with activeRefreshOffset set to
	activeRefresh for simplicity, is:		activeRefresh for simplicity, is:
	addWaitTime = addHoldDownTime		addWaitTime = addHoldDownTime
	+ SigExpirationTime		+ sigExpirationTime
	+ 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)
	)		)
	+ 2 * MAX(TTL of all records)		+ 2 * MAX(TTL of all records)
			6.1.7. 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 validating resolver may have received a		the last point at which a validating 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
	publication time plus SigExpirationTime. Thus, the latest time that		publication time plus sigExpirationTime. 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 seconds before the (DNSKEY RRSIG Signature		attacker can replay K_old seconds before the (DNSKEY RRSIG Signature
	Validity) field of the last K_old only RRSIG.		Validity) field of the last K_old only RRSIG.
	RFC5011 also discusses a retryTime value for failed queries. Our		6.1.8. Additional Considerations
	equation cannot take into account undeterministic failure situations,
	so it might be wise to extend the addWaitTime by some factor of
	retryTime, which is defined in RFC5011 as:
	retryTime = MAX (1 hour,
	MIN (1 day,
	.1 * TTL of K_old DNSKEY RRset,
	.1 * SigExpirationTime))
	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.
	Because the 5011 steps require direct validation using the signature
	validity, the authors aren't yet convinced it is needed in this
	particular case, but it is prudent to include it for added assurance.
	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 and not necessarily as
	critical.		critical.
	6.1.1. Example Results		6.1.8.1. Example Results
	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)		+ 2 * (1) (days)
	skipping to change at page 10, line 33 ¶		skipping to change at page 11, line 17 ¶
	It is important to note that this issue affects not just the		It is important to note that this issue affects not just the
	publication of new DNSKEYs intended to be used as trust anchors, but		publication of new DNSKEYs intended to be used as trust anchors, but
	also the length of time required to continuously publish a DNSKEY		also the length of time required to continuously publish a DNSKEY
	with the revoke bit set. Both of these publication timing		with the revoke bit set. Both of these publication timing
	requirements are affected by the attacks described in this document,		requirements are affected by the attacks described in this document,
	but with revocation the key is revoked immediately and the		but with revocation the key is revoked immediately and the
	addHoldDown timer does not apply. Thus the minimum amount of time		addHoldDown timer does not apply. Thus the minimum amount of time
	that a Trust Anchor Publisher must wait before removing a revoked key		that a Trust Anchor Publisher must wait before removing a revoked key
	from publication is:		from publication is:
	remWaitTime = SigExpirationTime		remWaitTime = sigExpirationTime
	+ 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)		1 hour)
	+ 2 * MAX(TTL of all records)		+ 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 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 the 2*TTL safety
	margin, though that is an operational consideration and not		margin, though that is an operational consideration and not
	necessarily as critical.		necessarily as critical.
	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.2.1. Example Results		6.2.1. Example Results
	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
	+ 2 * (1) (days)		+ 2 * (1) (days)
	remwaitTime = 12.5 (days)		remwaitTime = 12.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 Validator into leaving a trust		much harder job tricking a RFC5011 Validator 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 Validator sends, not just one.		data for every query a RFC5011 Validator sends, not just one.
	7. IANA Considerations		7. IANA Considerations
	This document contains no IANA considerations.		This document contains no IANA considerations.
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 38 ¶
	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 /
	DNSKEYs. Thus the entire document is a discussion of Security		DNSKEYs. Thus the entire document is a discussion of Security
	Considerations when adding or removing DNSKEYs from trust anchor		Considerations when adding or removing DNSKEYs from trust anchor
	storage using the RFC5011 process.		storage using the RFC5011 process.
	For simplicity, this document assumes that the Trust Anchor Publisher		For simplicity, this document assumes that the Trust Anchor Publisher
	will use a consistent RRSIG validity period. Trust Anchor Publishers		will use a consistent RRSIG validity period. Trust Anchor Publishers
	that vary the length of RRSIG validity periods will need to adjust		that vary the length of RRSIG validity periods will need to adjust
	the SigExpirationTime value accordingly so that the equations in		the sigExpirationTime value accordingly so that the equations in
	Section 6 and Section 6.2 use a value that coincides with the last		Section 6 and Section 6.2 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.
	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, and the dnsop working group who have		Duane Wessels, Petr Petr Spacek, Ed Lewis, and the dnsop working
	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,		Requirement Levels", BCP 14, RFC 2119, March 1997.
	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,
	<https://www.rfc-editor.org/info/rfc4033>.		<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, <https://www.rfc-editor.org/info/rfc5011>.		September 2007, <http://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, <https://www.rfc-editor.org/info/rfc7719>.		2015, <http://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, ICANN expects to (or has, depending on when you're reading
	this) roll the key signing key (KSK) for the root zone. The relevant		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		parameters associated with the root zone at the time of this writing
	is as follows:		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):
	addWaitTime = 30		addWaitTime = 30
	+ (21)		+ (21)
	+ MAX(MIN((21) / 2,		+ MAX(MIN((21) / 2,
	MAX(2 / 2,		MAX(2 / 2,
	15 days)),		15 days)),
End of changes. 40 change blocks.
	62 lines changed or deleted		97 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/