< draft-ietf-dnsop-rfc5011-security-considerations-01.txt		draft-ietf-dnsop-rfc5011-security-considerations-02.txt >
	dnsop W. Hardaker		dnsop W. Hardaker
	Internet-Draft USC/ISI		Internet-Draft USC/ISI
	Intended status: Standards Track W. Kumari		Intended status: Standards Track W. Kumari
	Expires: November 21, 2017 Google		Expires: December 29, 2017 Google
	May 20, 2017		June 27, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-ietf-dnsop-rfc5011-security-considerations-01		draft-ietf-dnsop-rfc5011-security-considerations-02
	Abstract		Abstract
	This document describes the math behind the minimum time-length that		This document extends the RFC5011 rollover strategy with timing
	a DNS zone publisher must wait before using a new DNSKEY to sign		advice that must be followed in order to maintain security.
	records when supporting the RFC5011 rollover strategies.		Specifically, this document describes the math behind the minimum
			time-length that a DNS zone publisher must wait before signing with
			only recently added DNSKEYs. 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 November 21, 2017.		This Internet-Draft will expire on December 29, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Document History and Motivation . . . . . . . . . . . . . 2		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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		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 . . . . . . . . . . . 4
	4.2. Timing Associated with Revocation . . . . . . . . . . . . 4		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 . . . . . . . . . . . . . . . . 5
	5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6		5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6
	6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 7		6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Operational Considerations . . . . . . . . . . . . . . . . . 9		8. Operational Considerations . . . . . . . . . . . . . . . . . 9
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 9		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	11. Normative References . . . . . . . . . . . . . . . . . . . . 9		11. Normative References . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 10		Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 10
	Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 11		Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	[RFC5011] defines a mechanism by which DNSSEC validators can extend		[RFC5011] defines a mechanism by which DNSSEC validators can extend
	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 a newly published key for signing records or how long they must		to using only recently published keys for signing records, or how
	wait before removing a revoked key from a zone. Because of this lack		long they must wait before removing a revoked key from a zone.
	of guidance, zone publishers may derive incorrect assumptions about		Because of this lack of guidance, zone publishers may derive
	safe usage of the RFC5011 DNSKEY advertising, rolling and revocation		incorrect assumptions about safe usage of the RFC5011 DNSKEY
	process. This document describes the minimum security requirements		advertising, rolling and revocation process. This document describes
	from a publisher's point of view and is intended to compliment the		the minimum security requirements from a publisher's point of view
	guidance offered in RFC5011 (which is written to provide timing		and is intended to compliment the guidance offered in RFC5011 (which
	guidance solely to a Validating Resolver's point of view).		is written to provide timing guidance solely to a Validating
			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 using a new KSK [RFC4033] that		they must wait before signing a zone using a new KSK [RFC4033] that
	was being rolled according to the 5011 process. All 5 experts		was being rolled according to the 5011 process. All 5 experts
	answered with an insecure value, and we determined that this lack of		answered with an insecure value, and we determined that this lack of
	operational guidance is causing security concerns today and wrote		operational guidance is causing security concerns today and wrote
	this companion document to RFC5011. We hope that this document will		this companion document to RFC5011. We hope that this document will
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 32 ¶
	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 Validating		The RFC5011 process describes a process by which a RFC5011 Validating
	Resolver may accept a newly published KSK as a trust anchor for		Resolver may accept a newly published KSK as a trust anchor for
	validating future DNSSEC signed records. It also describes the		validating future DNSSEC signed records. It also describes the
	process for publicly revoking a published KSK. This document		process for publicly revoking a published KSK. This document
	augments that information with additional constraints, as required		augments that information with additional constraints, as required
	from the DNSKEY publication and revocation's points of view. Note		from the DNSKEY publication and revocation's points of view. Note
	that it does not define any other operational guidance or		that it does not define any other operational guidance or
	recommendations about the RFC5011 process and restricts itself to		recommendations about the RFC5011 process and restricts itself to
	solely the security and operational ramifications of switching to a		solely the security and operational ramifications of switching to
	new key or removing a revoked key too soon. Failure of a DNSKEY		using only recently added keys or removing a revoked keys too soon.
	publisher to follow the minimum recommendations associated with this		Failure of a DNSKEY publisher to follow the minimum recommendations
	draft will result in potential denial-of-service attack opportunities		associated with this draft will result in potential denial-of-service
	against validating resolvers or in revoked old DNSKEYs remaining in		attack opportunities against validating resolvers. Failure of a
	the trust anchor storage of validating resolvers beyond their		DNSKEY publisher to publish a revoked key for a long enough period of
	expected valid lifetime.		time may result in RFC5011 Validating Resolvers leaving a key in
			their trust anchor storage beyond their expected lifetime.
	3. Terminology		3. Terminology
	Trust Anchor Publisher The entity responsible for publishing a		Trust Anchor Publisher The entity responsible for publishing a
	DNSKEY that can be used as a trust anchor.		DNSKEY that can be used as a trust anchor.
	Zone Signer The owner of a zone intending to publish a new Key-		Zone Signer The owner of a zone intending to publish a new Key-
	Signing-Key (KSK) that will become a trust anchor by validators		Signing-Key (KSK) that will become a trust anchor by validators
	following the RFC5011 process.		following the RFC5011 process.
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 39 ¶
	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:		by the Trust Anchor Publisher:
	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 using the new DNSKEY to sign the appropriate resource		3. Begin using only recently published DNSKEYs to sign the
	records.		appropriate resource records.
	This document discusses step 2 of the above process. Some		This document discusses step 2 of the above process. Some
	interpretations of RFC5011 have erroneously determined that the wait		interpretations of RFC5011 have erroneously determined that the wait
	time is equal to RFC5011's "hold down time".		time is equal to RFC5011's "hold down time".
	Section 5 describes an attack based on this (common) erroneous		Section 5 describes an attack based on this (common) erroneous
	belief, which results in a denial of service attack against the zone		belief, which results in a denial of service attack against the zone
	if that value is used.		if that value is used.
	4.2. Timing Associated with Revocation		4.2. Timing Associated with Revocation
	skipping to change at page 9, line 42 ¶		skipping to change at page 10, line 16 ¶
	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, and the dnsop working group who have
	assisted with this document.		assisted with this document.
	11. Normative References		11. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119, March 1997.
	DOI 10.17487/RFC2119, March 1997,
	<http://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>.		<http://www.rfc-editor.org/info/rfc4033>.
	[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)		[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
	Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,		Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
	September 2007, <http://www.rfc-editor.org/info/rfc5011>.		September 2007, <http://www.rfc-editor.org/info/rfc5011>.
	skipping to change at page 11, line 51 ¶		skipping to change at page 12, line 30 ¶
	Changed min wait time math to include TTL value as well		Changed min wait time math to include TTL value as well
	From -03 to -04:		From -03 to -04:
	Fixed the waitTime equation to handle the difference between the		Fixed the waitTime equation to handle the difference between the
	usage of the expiration time and the Active Refresh time.		usage of the expiration time and the Active Refresh time.
	More clarification text and text changes proposed by Petr Spacek		More clarification text and text changes proposed by Petr Spacek
	From hardaker-04 to ietf-00:		From -04 to -05:
			Clarifications about signing using only new keys, vs old ones too
			Pre-DNSOP document: From hardaker-04 to ietf-00:
	Just rebranding.		Just rebranding.
	From ietf-00 to ietf-01:		From ietf-00 to ietf-01:
	Added discussion surrounding revocation everywhere		Added discussion surrounding revocation everywhere
	Fixed the text about the formula		Fixed the text about the formula
	Another complete re-read for word-smithing		Another complete re-read for word-smithing
End of changes. 14 change blocks.
	34 lines changed or deleted		44 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/