< draft-ietf-dnsop-rfc5011-security-considerations-09.txt		draft-ietf-dnsop-rfc5011-security-considerations-10.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 10, 2018 December 07, 2017		Expires: June 22, 2018 December 19, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-ietf-dnsop-rfc5011-security-considerations-09		draft-ietf-dnsop-rfc5011-security-considerations-10
	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 by the publisher in order to maintain		advice that must be followed by the publisher in order to maintain
	security. Specifically, this document describes the math behind the		security. Specifically, this document describes the math behind the
	minimum time-length that a DNS zone publisher must wait before		minimum time-length that a DNS zone publisher must wait before
	signing exclusively with recently added DNSKEYs. This document also		signing exclusively with recently added DNSKEYs. This document also
	describes the minimum time-length that a DNS zone publisher must wait		describes the minimum time-length that a DNS zone publisher must wait
	after publishing a revoked DNSKEY before assuming that all active		after publishing a revoked DNSKEY before assuming that all active
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 10, 2018.		This Internet-Draft will expire on June 22, 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 35 ¶		skipping to change at page 2, line 35 ¶
	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 . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . 8		6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8
	6.1. Equation Components . . . . . . . . . . . . . . . . . . . 8		6.1. Equation Components . . . . . . . . . . . . . . . . . . . 9
	6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 9		6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 9
	6.1.2. lastSigExpirationTime . . . . . . . . . . . . . . . . 9		6.1.2. lastSigExpirationTime . . . . . . . . . . . . . . . . 9
	6.1.3. sigExpirationTime . . . . . . . . . . . . . . . . . . 9		6.1.3. sigExpirationTime . . . . . . . . . . . . . . . . . . 9
	6.1.4. sigExpirationTimeRemaining . . . . . . . . . . . . . 9		6.1.4. sigExpirationTimeRemaining . . . . . . . . . . . . . 9
	6.1.5. sigExpirationTimeRemaining . . . . . . . . . . . . . 9		6.1.5. activeRefresh . . . . . . . . . . . . . . . . . . . . 9
	6.1.6. activeRefresh . . . . . . . . . . . . . . . . . . . . 9		6.1.6. activeRefreshOffset . . . . . . . . . . . . . . . . . 10
	6.1.7. activeRefreshOffset . . . . . . . . . . . . . . . . . 10		6.1.7. driftSafetyMargin . . . . . . . . . . . . . . . . . . 10
	6.1.8. safetyMargin . . . . . . . . . . . . . . . . . . . . 10		6.1.8. timingSafetyMargin . . . . . . . . . . . . . . . . . 10
	6.2. Timing Requirements For Adding a New KSK . . . . . . . . 11		6.1.9. retrySafetyMargin . . . . . . . . . . . . . . . . . . 11
	6.2.1. Wait Timer Based Calculation . . . . . . . . . . . . 11		6.2. Timing Requirements For Adding a New KSK . . . . . . . . 12
	6.2.2. Wall-Clock Based Calculation . . . . . . . . . . . . 12		6.2.1. Wait Timer Based Calculation . . . . . . . . . . . . 12
			6.2.2. Wall-Clock Based Calculation . . . . . . . . . . . . 13
	6.2.3. Timing Constraint Summary . . . . . . . . . . . . . . 13		6.2.3. Timing Constraint Summary . . . . . . . . . . . . . . 13
	6.2.4. Additional Considerations for RFC7583 . . . . . . . . 13		6.2.4. Additional Considerations for RFC7583 . . . . . . . . 14
	6.2.5. Example Scenario Calculations . . . . . . . . . . . . 13		6.2.5. Example Scenario Calculations . . . . . . . . . . . . 14
	6.3. Timing Requirements For Revoking an Old KSK . . . . . . . 14		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 . . . . . . . . . . . . 15
	6.3.2. Wall-Clock Based Calculation . . . . . . . . . . . . 14		6.3.2. Wall-Clock Based Calculation . . . . . . . . . . . . 15
	6.3.3. Additional Considerations for RFC7583 . . . . . . . . 15		6.3.3. Additional Considerations for RFC7583 . . . . . . . . 16
	6.3.4. Example Scenario Calculations . . . . . . . . . . . . 15		6.3.4. Example Scenario Calculations . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Operational Considerations . . . . . . . . . . . . . . . . . 16		8. Operational Considerations . . . . . . . . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	11. Normative References . . . . . . . . . . . . . . . . . . . . 17		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 . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		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
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	only 26 days, it failed to ever accept K_new as a trust anchor.		only 26 days, it failed to ever accept K_new as a trust anchor.
	Since K_old is no longer being used to sign the zone's DNSKEYs,		Since K_old is no longer being used to sign the zone's DNSKEYs,
	all the DNSKEY records from the zone will be treated as invalid.		all the DNSKEY records from the zone will be treated as invalid.
	Subsequently, all of the records in the DNS tree below the zone's		Subsequently, all of the records in the DNS tree below the zone's
	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. We break our
	the term components used in both equations in Section 6.1.		timing solution requirements into two primary components: the
			mathematically-based security analysis of the RFC5011 publication
			process itself, and an extension of this that takes operational
			realities into account that further affect the recommended timings.
			First, we define the term components used in all 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.
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 33 ¶
	the future unless they can be significantly assured that none of		the future unless they can be significantly assured that none of
	their pre-generated signatures can be replayed at a later date.		their pre-generated signatures can be replayed at a later date.
	6.1.3. sigExpirationTime		6.1.3. sigExpirationTime
	The amount of time between the DNSKEY RRSIG's Signature Inception		The amount of time between the DNSKEY RRSIG's Signature Inception
	field and the Signature Expiration field.		field and the Signature Expiration field.
	6.1.4. sigExpirationTimeRemaining		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.6. activeRefresh		6.1.5. 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.7. activeRefreshOffset		6.1.6. 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.
	simplicity, setting the activeRefreshOffset to the activeRefresh
	value itself is always safe.
	6.1.8. safetyMargin		Note that later (in Section 6.1.8), when real-world scenerios will
			trump this value that is useful only in theoretical worlds with no
			network delays and other operational considerations. We leave it
			here only as an important marker in the security analysis of the base
			RFC5011 protocol.
	The safetyMargin is an extra period of time to account for caching,		6.1.7. driftSafetyMargin
	network delays, dropped packets, and other operational concerns
	otherwise beyond the scope of this document. The value operators		Moving past the theoretical model parameters above, we not that clock
	should chose is highly dependent on the deployment situation		drift, network delays and implementation differences will result in
	associated with their zone. Note that no value of a safetyMargin can		the RFC5011 Resolver query times to drift over time. Because of
	protect against resolvers that are "down". None the less, we do		this, a driftSafetyMargin term must be introduce that accounts for
	offer the following as one method considering reasonable values to		these real world delays. We set this value to be the same as the
	select from.		activeRefresh value, which will ensure that any timing drift in
			RFC5011 Resolver queries will be accounted for.
			Note: even a negative clock drift can actually cause RFC5011
			Resolvers to require up to an extra activeRefresh period before it
			will accept a new DNSKEY as a trust anchor.
			6.1.8. timingSafetyMargin
			Both of the activeRefreshOffset and driftSafetyMargin parameters deal
			with timing delays introduced by mathematical analysis of RFC5011
			(activeRefreshOffset) and by real world considerations
			(driftSafetyMargin). To find a safe value to extend timing, we
			define a timingSafetyMargin that is the maximum of these two values.
			Since the driftSafetyMargin is set to activeRefresh, and
			activeRefreshOffset is always less than an activeRefresh, the final
			timingSafetyMargin value will be activeRefresh.
			Explicitly expanding out the math:
			timingSafetyMargin = min(activeRefreshOffset, driftSafetyMargin)
			timingSafetyMargin = min(addHoldDownTime % activeRefresh,
			activeRefresh)
			timingSafetyMargin = activeRefresh
			6.1.9. retrySafetyMargin
			The retrySafetyMargin is an extra period of time to account for
			caching, network delays, dropped packets, and other operational
			concerns otherwise beyond the scope of this document. The value
			operators should chose is highly dependent on the deployment
			situation associated with their zone. Note that no value of a
			retrySafetyMargin can protect against resolvers that are "down".
			None the less, we do offer the following as one method considering
			reasonable values to 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 retrySafetyMargin value:
	successRate: A likely success rate for client queries and retries		successRate: A likely success rate for client queries and retries
	numResolvers: The number of client RFC5011 Resolvers		numResolvers: The number of client RFC5011 Resolvers
	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
	skipping to change at page 11, line 13 ¶		skipping to change at page 12, line 5 ¶
	uncompleted servers to 0 assuming 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 retrySafetyMargin can then be this
	retryCountWait number multiplied by the retryTime from RFC5011:		retryCountWait number multiplied by the retryTime from RFC5011:
	safetyMargin = retryCountWait * retryTime		retrySafetyMargin = retryCountWait * retryTime
	6.2. Timing Requirements For Adding a New KSK		6.2. Timing Requirements For Adding a New KSK
	Section 6.2.1 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 DNSKEY		wait until it is safe to start signing exclusively with a new DNSKEY
	(especially useful for writing code involving sleep based timers),		(especially useful for writing code involving sleep based timers),
	and Section 6.2.2 defines 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 DNSKEY		after which it is safe to start signing exclusively with a new DNSKEY
	(especially useful for writing code based on clock-based event		(especially useful for writing code based on clock-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		+ timingSafetyMargin
	+ safetyMargin		+ retrySafetyMargin
	6.2.1.1. Fully expanded equation		6.2.1.1. Fully expanded equation
	Given the equation components defined in Section 6.1, the full		Given the equation components defined in Section 6.1, the full
	expanded equation is:		expanded equation is:
	addWaitTime = addHoldDownTime		addWaitTime = addHoldDownTime
	+ sigExpirationTimeRemaining		+ 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)
	)		)
	+ (addHoldDownTime % activeRefresh)		+ activeRefresh
	+ MAX(1.5 hours, 2 * MAX(TTL of all records))		+ retrySafetyMargin
	+ safetyMargin
	6.2.2. Wall-Clock Based Calculation		6.2.2. Wall-Clock Based Calculation
	The equations in Section 6.2.1 are defined based upon how long to		The equations in Section 6.2.1 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 use a key 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		+ timingSafetyMargin
	+ safetyMargin		+ retrySafetyMargin
	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)		+ activeRefresh
	+ MAX(1.5 hours, 2 * MAX(TTL of all records))		+ retrySafetyMargin
	+ 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 old		without the potential for a replay attack will occur after the old
	DNSKEY RRSIG's Signature Expriation Time. 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
	skipping to change at page 13, line 40 ¶		skipping to change at page 14, line 22 ¶
	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.		though that is an operational consideration.
	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, our resulting addWaitTime
	0, since 30 days is evenly divisible by activeRefresh (1/2 day), and		is:
	our resulting addWaitTime is:
	addWaitTime = 30		addWaitTime = 30
	+ 10		+ 10
	+ 1 / 2		+ 1 / 2
	+ 0 (days)		+ 1 / 2 (days)
	addWaitTime = 42.5 (days)		addWaitTime = 43 (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, even with the needed safetyMargin value being left out		down timer, even with the needed retrySafetyMargin value being left
	(which we exclude due to the lack of necessary operational		out (which we exclude due to the lack of necessary operational
	parameters).		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.
	Section 6.2.1 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
	skipping to change at page 14, line 31 ¶		skipping to change at page 15, line 15 ¶
	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		+ activeRefresh
	+ safetyMargin		+ timingSafetyMargin
			+ retrySafetyMargin
	remWaitTime = sigExpirationTimeRemaining		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))
	+ safetyMargin		+ activeRefresh
			+ retrySafetyMargin
	Note that the activeRefreshOffset time does not apply to this
	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
	+ safetyMargin		+ timingSafetyMargin
			+ retrySafetyMargin
	remWallClockTime = lastSigExpirationTime		remWallClockTime = lastSigExpirationTime
	+ 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))
	+ safetyMargin		+ timingSafetyMargin
			+ retrySafetyMargin
	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:
	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.
	skipping to change at page 16, line 42 ¶		skipping to change at page 17, line 25 ¶
	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		and his continued reviews and suggestions for this document. He also
	designed the suggested math behind the suggested safetyMargin values		designed the suggested math behind the suggested retrySafetyMargin
	in Section 6.1.8.		values in Section 6.1.9.
	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,		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 and 2018, ICANN expects to (or has, depending on when you're		In 2017 and 2018, ICANN expects to (or has, depending on when you're
	reading this) roll the key signing key (KSK) for the root zone. The		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		relevant parameters associated with the root zone at the time of this
	writing is as follows:		writing is as follows:
	addHoldDownTime: 30 days		addHoldDownTime: 30 days
	Old DNSKEY sigExpirationTime: 21 days		Old DNSKEY sigExpirationTime: 21 days
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 30 ¶
	Thus, sticking this information into the equation in		Thus, sticking this information into the equation in
	Section Section 6 yields (in days from publication time):		Section Section 6 yields (in days from publication time):
	addWaitTime = 30		addWaitTime = 30
	+ 21		+ 21
	+ MAX(1 hour,		+ MAX(1 hour,
	MIN(21 / 2, # activeRefresh		MIN(21 / 2, # activeRefresh
	MAX(2) / 2,		MAX(2) / 2,
	15 days),		15 days),
	)		)
	+ 30 % activeRefresh		+ activeRefresh
	addWaitTime = 30 + 21
	+ MAX(1 hour, MIN(11.5, 1, 15)))
	+ 30 % activeRefresh
	addWaitTime = 30 + 21 + 1 + 30%1
	addWaitTime = 30 + 21 + 1 + 0
	addWaitTime = 52 days		addWaitTime = 30 + 21 + 1 + 1
	Note that activeRefreshOffset ends up being 0, since 30 days is		addWaitTime = 53 days
	evenly divisible by activeRefresh (1 day).
	Also note that we exclude the safetyMargin value, which is calculated		Also note that we exclude the retrySafetyMargin value, which is
	based on the expected client deployment size.		calculated based on the expected client deployment size.
	Thus, ICANN must wait a minimum of 52 days before switching to the		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 involve		once it is published as revoked). ICANN's current plans involve
	waiting over 3 months before using the new KEY and 69 days before		waiting over 3 months before using the new KEY and 69 days before
	removing the old, revoked key. Thus, their current rollover plans		removing the old, revoked key. Thus, their current rollover plans
	are sufficiently 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
	Warren Kumari		Warren Kumari
	Google		Google
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, CA 94043		Mountain View, CA 94043
	US		US
	Email: warren@kumari.net		Email: warren@kumari.net
End of changes. 45 change blocks.
	96 lines changed or deleted		125 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/