< draft-hardaker-rfc5011-security-considerations-03.txt		draft-hardaker-rfc5011-security-considerations-04.txt >
	dnsop W. Hardaker		dnsop W. Hardaker
	Internet-Draft Parsons, Inc.		Internet-Draft Parsons, Inc.
	Intended status: Standards Track W. Kumari		Intended status: Standards Track W. Kumari
	Expires: August 20, 2017 Google		Expires: August 21, 2017 Google
	February 16, 2017		February 17, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-hardaker-rfc5011-security-considerations-03		draft-hardaker-rfc5011-security-considerations-04
	Abstract		Abstract
	This document describes the math behind the minimum time-length that		This document describes the math behind the minimum time-length that
	a DNS zone publisher must wait before using a new DNSKEY to sign		a DNS zone publisher must wait before using a new DNSKEY to sign
	records when supporting the RFC5011 rollover strategies.		records when supporting the RFC5011 rollover strategies.
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 August 20, 2017.		This Internet-Draft will expire on August 21, 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
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	signed by K_new will be treated as invalid. Subsequently, all		signed by K_new will be treated as invalid. Subsequently, all
	keys in the key set are now unusable, invalidating all records in		keys in the key set are now unusable, invalidating all records in
	the zone of any type and name.		the zone of any type and name.
	6. Minimum RFC5011 Timing Requirements		6. Minimum RFC5011 Timing Requirements
	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 before using K_new is:		of time required for the Zone Signer to wait before using K_new is:
	waitTime = addHoldDownTime		waitTime = addHoldDownTime
	+ MIN(3 * (DNSKEY RRSIG Signature Validity) / 2,		+ (DNSKEY RRSIG Signature Validity)
	3 * MAX(original TTL of K_old DNSKEY RRSet) / 2,		+ MAX(MIN((DNSKEY RRSIG Signature Validity) / 2,
	15 days)		MAX(original TTL of K_old DNSKEY RRSet) / 2,
			15 days),
			1 hour)
	+ 2 * MAX(TTL of all records)		+ 2 * MAX(TTL of all records)
	The most confusing element of the above equation comes from the "3 *		The most confusing element of the above equation comes from the "3 *
	(DNSKEY RRSIG Signature Validity) / 2" element, but is the most		(DNSKEY RRSIG Signature Validity) / 2" element, but is the most
	critical to understand and get right.		critical to understand and get right.
	The RFC5011 "Active Refresh" requirements state that:		The RFC5011 "Active Refresh" requirements state that:
	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.
	The important timing constraint that must be considered is the last		The important timing constraint that must be considered is the last
	point at which a validating resolver may have received a replayed the		point at which a validating resolver may have received a replayed the
	original DNSKEY set (K_old) without the new key. It's the next query		original DNSKEY set (K_old) without the new key. It's the next query
	of the RFC5011 validator that the assured K_new will be seen. For		of the RFC5011 validator that the assured K_new will be seen. Thus,
	the following paragraph, we use the more common case where (DNSKEY		the latest time a RFC5011 validator may begin their hold down timer
	RRSIG Signature Validity) is greater than (original TTL for the		is an "Active Refresh" period after the last point that an attacker
	DNSKEY RRSet), although the equation above takes both cases into		can replay the K_old DNSKEY set.
	account.
			The "Active Refresh" interval used by RFC5011 validator is determined
			by the larger of (DNSKEY RRSIG Signature Validity) and (original TTL
			for the DNSKEY RRSet). The Following text assumes that (DNSKEY RRSIG
			Signature Validity) is larger of the two, which is operationally more
			common today.
	Thus, the worst case scenario of this attack is when the attacker can		Thus, the worst case scenario of this attack is when the attacker can
	replay K_old at just before (DNSKEY RRSIG Signature Validity). If a		replay K_old at just before (DNSKEY RRSIG Signature Validity). If a
	RFC5011 validator picks up K_old at this this point, it will not have		RFC5011 validator picks up K_old at this this point, it will not have
	a hold down timer started at all. It's not until the next "Active		a hold down timer started at all. It's not until the next "Active
	Refresh" time that they'll pick up K_new with assurance, and thus		Refresh" time that they'll pick up K_new with assurance, and thus
	start their hold down timer. Thus, this is not at (DNSKEY RRSIG		start their hold down timer. Thus, this is not at (DNSKEY RRSIG
	Signature Validity) time past publication, but rather 3 * (DNSKEY		Signature Validity) time past publication, but rather 3 * (DNSKEY
	RRSIG Signature Validity) / 2.		RRSIG Signature Validity) / 2.
	The extra 2 * MAX(TTL of all records) is the standard added safety		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.		margin when dealing with DNSSEC due to caching that can take place.
	Because the 5011 steps require direct validation using the signature		Because the 5011 steps require direct validation using the signature
	validity, the authors aren't yet convinced it is needed in this		validity, the authors aren't yet convinced it is needed in this
	particular case.		particular case.
	For the parameters listed in Section 5.1, our example:		For the parameters listed in Section 5.1, our example:
	waitTime = 30		waitTime = 30
	+ 3 * (10) / 2		+ 10
			+ 10 / 2
	+ 2 * (1) (days)		+ 2 * (1) (days)
	waitTime = 47 (days)		waitTime = 47 (days)
	This hold-down time of 47 days is 12 days longer than the frequently		This hold-down time of 47 days is 12 days longer than the frequently
	perceived 35 days in T+35 above.		perceived 35 days in T+35 above.
	7. IANA Considerations		7. IANA Considerations
	This document contains no IANA considerations.		This document contains no IANA considerations.
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 26 ¶
	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 /
	keys. Thus the entire document is a discussion of Security		keys. Thus the entire document is a discussion of Security
	Considerations		Considerations
	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. We would also like to thank Bob Harold, Shane Kerr,		help and advice. We would also like to thank Bob Harold, Shane Kerr,
	Matthijs Mekking, Duane Wessels, and everyone else who assisted with		Matthijs Mekking, Duane Wessels, Petr Spa&#269;ek, and everyone else
	this document.		who 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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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,
	skipping to change at page 9, line 11 ¶		skipping to change at page 9, line 18 ¶
	Changed to " <?rfc include='reference....'?> " style references.		Changed to " <?rfc include='reference....'?> " style references.
	From -02 to -03:		From -02 to -03:
	Minor changes from Bob Harold		Minor changes from Bob Harold
	Clarified why 3/2 signature validity is needed		Clarified why 3/2 signature validity is needed
	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:
			Fixed the waitTime equation to handle the difference between the
			usage of the expiration time and the Active Refresh time.
			More clarification text and text changes proposed by Petr
			Spa&#269;ek
	Authors' Addresses		Authors' Addresses
	Wes Hardaker		Wes Hardaker
	Parsons, Inc.		Parsons, Inc.
	P.O. Box 382		P.O. Box 382
	Davis, CA 95617		Davis, CA 95617
	US		US
	Email: ietf@hardakers.net		Email: ietf@hardakers.net
End of changes. 8 change blocks.
	15 lines changed or deleted		31 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/