< draft-ietf-dnsop-rfc5011-security-considerations-04.txt		draft-ietf-dnsop-rfc5011-security-considerations-05.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 17, 2018 September 13, 2017		Expires: March 23, 2018 September 19, 2017
	Security Considerations for RFC5011 Publishers		Security Considerations for RFC5011 Publishers
	draft-ietf-dnsop-rfc5011-security-considerations-04		draft-ietf-dnsop-rfc5011-security-considerations-05
	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 17, 2018.		This Internet-Draft will expire on March 23, 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 9, line 22 ¶		skipping to change at page 9, line 22 ¶
	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		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 the addHoldDownTime.
	activeRefreshOffset will be "(30 days) % activeRefresh", where % is		Specifically, activeRefreshOffset will be "addHoldDownTime %
	the mathematical mod operator (which calculates the remainder in a		activeRefresh", where % is the mathematical mod operator (calculating
	division problem). This will frequently be zero, but could be nearly		the remainder in a division problem). This will frequently be zero,
	as large as activeRefresh itself. For simplicity, setting the		but could be nearly as large as activeRefresh itself. For
	activeRefreshOffset to the activeRefresh value itself is safe.		simplicity, setting the activeRefreshOffset to the activeRefresh
			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)
	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
End of changes. 4 change blocks.
	9 lines changed or deleted		10 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/