< draft-ietf-dnsop-rfc5011-security-considerations-05.txt		draft-ietf-dnsop-rfc5011-security-considerations-06.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 23, 2018 September 19, 2017		Expires: April 19, 2018 October 16, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-ietf-dnsop-rfc5011-security-considerations-05		draft-ietf-dnsop-rfc5011-security-considerations-06
	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. It contains much math and		exclusively with recently added DNSKEYs. It contains much math and
	complicated equations, but the summary is that the key rollover /		complicated equations, but the summary is that the key rollover /
	revocation time is much longer than intuition would suggest. If you		revocation time is much longer than intuition would suggest. If you
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 23, 2018.		This Internet-Draft will expire on April 19, 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 28 ¶		skipping to change at page 2, line 28 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 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 Considerations . . . . . . . . . . . 5		5. Denial of Service Attack Considerations . . . . . . . . . . . 6
	5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6		5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6
	5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6		5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 7
	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. addHoldDownTime . . . . . . . . . . . . . . . . . . . 8		6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 8
	6.1.2. sigExpirationTime . . . . . . . . . . . . . . . . . . 8		6.1.2. sigExpirationTime . . . . . . . . . . . . . . . . . . 9
	6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 8		6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 9
	6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9		6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9
	6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 9		6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 9
	6.1.6. Fully expanded equation . . . . . . . . . . . . . . . 9		6.1.6. Fully expanded equation . . . . . . . . . . . . . . . 10
	6.1.7. Timing Constraint Summary . . . . . . . . . . . . . . 10		6.1.7. Timing Constraint Summary . . . . . . . . . . . . . . 10
	6.1.8. Additional Considerations . . . . . . . . . . . . . . 10		6.1.8. Additional Considerations . . . . . . . . . . . . . . 11
	6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 11		6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 11
	6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 11		6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Operational Considerations . . . . . . . . . . . . . . . . . 12		8. Operational Considerations . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	11. Normative References . . . . . . . . . . . . . . . . . . . . 13		11. Normative References . . . . . . . . . . . . . . . . . . . . 13
	Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 13		Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		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.
	skipping to change at page 4, line 37 ¶		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 any existing
	Signature Expiration time is reached. This will fundamentally be		RRSIG's Signature Expiration time is reached. Note that for
	the RRSIG's Signature Expiration time minus the RRSIG's Signature		organizations pre-creating signatures this time may be fairly
	Inception time when the signature is created.		lengthy unless they can be significantly assured their signatures
			can not be replayed at a later date. sigExpirationTime will
			fundamentally be the RRSIG's Signature Expiration time minus the
			RRSIG's Signature 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.
	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 importance of this document.		fully comprehend the importance of this document.
	4.1. Timing Associated with Publication		4.1. Timing Associated with Publication
	RFC5011's process of safely publishing a new key and then making use		RFC5011's process of safely publishing a new key and then making use
	of that key falls into a number of high-level steps to be performed		of that key falls into a number of high-level steps to be performed
	by the Trust Anchor Publisher. This document discusses the following		by the Trust Anchor Publisher. This document discusses the following
	scenario, which is one of many possible combinations of operations		scenario, which the principle way RFC5011 is currently being used
	defined in Section 6 of RFC5011:		(even though Section 6 of RFC5011 suggests having a stand-by key
			available):
	1. Publish a new DNSKEY in the zone, but continue to sign the zone		1. Publish a new DNSKEY in the zone, but continue to sign the zone
	with the old one.		with the old one.
	2. Wait a period of time.		2. Wait a period of time.
	3. Begin to exclusively use recently published DNSKEYs to sign the		3. Begin to exclusively use recently published DNSKEYs to sign the
	appropriate resource records.		appropriate resource records.
	This document discusses step 2 of the above process. Some		This document discusses step 2 of the above process. Some
	skipping to change at page 6, line 51 ¶		skipping to change at page 7, line 16 ¶
	The steps shows an attack that foils the adoption of a new DNSKEY by		The steps shows an attack that foils the adoption of a new DNSKEY by
	a 5011 Validating Resolver when the Trust Anchor Publisher that		a 5011 Validating Resolver when the Trust Anchor Publisher that
	starts signing and publishing with the new DNSKEY too quickly.		starts signing and publishing with the new DNSKEY too quickly.
	T-1 The K_old based RRSIGs are being published by the Zone Signer.		T-1 The K_old based RRSIGs are being published by the Zone Signer.
	[It may also be signing ZSKs as well, but they are not relevant to		[It may also be signing ZSKs as well, but they are not relevant to
	this event so we will not talk further about them; we are only		this event so we will not talk further about them; we are only
	considering the RRSIGs that cover the DNSKEYs in this document.]		considering the RRSIGs that cover the DNSKEYs in this document.]
	The Attacker queries for, retrieves and caches this DNSKEY set and		The Attacker queries for, retrieves and caches this DNSKEY set and
	corresponding RRSIG signatures.		corresponding RRSIG signatures. Note that for simplicity we
			assume the signer is not pre-signing and creating "valid in the
			future" signature sets that may be stolen and replayed even later.
	T+0 The Zone Signer adds K_new to their zone and signs the zone's		T+0 The Zone Signer adds K_new to their zone and signs the zone's
	key set with K_old. The RFC5011 Validator (later to be under		key set with K_old. The RFC5011 Validator (later to be under
	attack) retrieves this new key set and corresponding RRSIGs and		attack) retrieves this new key set and corresponding RRSIGs and
	notices the publication of K_new. The RFC5011 Validator starts		notices the publication of K_new. The RFC5011 Validator starts
	the (30-day) hold-down timer for K_new. [Note that in a more		the (30-day) hold-down timer for K_new. [Note that in a more
	real-world scenario there will likely be a further delay between		real-world scenario there will likely be a further delay between
	the point where the Zone Signer publishes a new RRSIG and the		the point where the Zone Signer publishes a new RRSIG and the
	RFC5011 Validator notices its publication; though not shown in		RFC5011 Validator notices its publication; though not shown in
	this example, this delay is accounted for in the final solution		this example, this delay is accounted for in the final solution
	skipping to change at page 9, line 34 ¶		skipping to change at page 9, line 49 ¶
	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.5. 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, etc. A suggested operational value for this is 2 *		network delays, etc. A suggested operational value for this is 2 *
	MAX(TTL of all records)		MAX(TTL of all records) unless the TTLs are shorter than an hour, at
			which point they start affecting the calculations in the MIN() clause
			in the activeRefresh timer in Section 6.1.3. Thus, we suggest a
			safetyMargin of at least:
			safetyMargin = MAX (1.5 hours, 2 * MAX(TTL of all records))
	RFC5011 also discusses a retryTime value for failed queries. Our		RFC5011 also discusses a retryTime value for failed queries. Our
	equation cannot take into account undeterministic failure situations,		equation cannot take into account undeterministic failure situations,
	so it might be wise to extend the safetyMargin by some factor of		so it might be wise to extend the safetyMargin by some factor of
	retryTime, which is defined in RFC5011 as:		retryTime, which is defined in RFC5011 as:
	retryTime = MAX (1 hour,		retryTime = MAX (1 hour,
	MIN (1 day,		MIN (1 day,
	.1 * TTL of K_old DNSKEY RRset,		.1 * TTL of K_old DNSKEY RRset,
	.1 * sigExpirationTime))		.1 * sigExpirationTime))
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 31 ¶
	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)		+ (addHoldDownTime % activeRefresh)
			+ MAX(1.5 hours, 2 * MAX(TTL of all records))
	6.1.7. Timing Constraint Summary		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
End of changes. 17 change blocks.
	23 lines changed or deleted		35 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/