< draft-ietf-dnsop-rfc5011-security-considerations-10.txt   draft-ietf-dnsop-rfc5011-security-considerations-11.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 22, 2018 December 19, 2017 Expires: August 5, 2018 February 01, 2018
Security Considerations for RFC5011 Publishers Security Considerations for RFC5011 Publishers
draft-ietf-dnsop-rfc5011-security-considerations-10 draft-ietf-dnsop-rfc5011-security-considerations-11
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 22, 2018. This Internet-Draft will expire on August 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 9 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. activeRefresh . . . . . . . . . . . . . . . . . . . . 9 6.1.5. activeRefresh . . . . . . . . . . . . . . . . . . . . 9
6.1.6. activeRefreshOffset . . . . . . . . . . . . . . . . . 10 6.1.6. timingSafetyMargin . . . . . . . . . . . . . . . . . 10
6.1.7. driftSafetyMargin . . . . . . . . . . . . . . . . . . 10 6.1.7. retrySafetyMargin . . . . . . . . . . . . . . . . . . 12
6.1.8. timingSafetyMargin . . . . . . . . . . . . . . . . . 10 6.2. Timing Requirements For Adding a New KSK . . . . . . . . 13
6.1.9. retrySafetyMargin . . . . . . . . . . . . . . . . . . 11 6.2.1. Wait Timer Based Calculation . . . . . . . . . . . . 14
6.2. Timing Requirements For Adding a New KSK . . . . . . . . 12 6.2.2. Wall-Clock Based Calculation . . . . . . . . . . . . 14
6.2.1. Wait Timer Based Calculation . . . . . . . . . . . . 12 6.2.3. Timing Constraint Summary . . . . . . . . . . . . . . 15
6.2.2. Wall-Clock Based Calculation . . . . . . . . . . . . 13 6.2.4. Additional Considerations for RFC7583 . . . . . . . . 15
6.2.3. Timing Constraint Summary . . . . . . . . . . . . . . 13 6.2.5. Example Scenario Calculations . . . . . . . . . . . . 15
6.2.4. Additional Considerations for RFC7583 . . . . . . . . 14 6.3. Timing Requirements For Revoking an Old KSK . . . . . . . 16
6.2.5. Example Scenario Calculations . . . . . . . . . . . . 14 6.3.1. Wait Timer Based Calculation . . . . . . . . . . . . 16
6.3. Timing Requirements For Revoking an Old KSK . . . . . . . 14 6.3.2. Wall-Clock Based Calculation . . . . . . . . . . . . 16
6.3.1. Wait Timer Based Calculation . . . . . . . . . . . . 15 6.3.3. Additional Considerations for RFC7583 . . . . . . . . 17
6.3.2. Wall-Clock Based Calculation . . . . . . . . . . . . 15 6.3.4. Example Scenario Calculations . . . . . . . . . . . . 17
6.3.3. Additional Considerations for RFC7583 . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.3.4. Example Scenario Calculations . . . . . . . . . . . . 16 8. Operational Considerations . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Operational Considerations . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Normative References . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 19
11. Normative References . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 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
how long they must wait before ceasing publication of a revoked key. how long they must wait before ceasing publication of a revoked key.
Because of this lack of guidance, zone publishers may derive Because of this lack of guidance, zone publishers may derive
incorrect assumptions about safe usage of the RFC5011 DNSKEY incorrect assumptions about safe usage of the RFC5011 DNSKEY
advertising, rolling and revocation process. This document describes advertising, rolling and revocation process. This document describes
the minimum security requirements from a publisher's point of view the minimum security requirements from a publisher's point of view
and is intended to complement the guidance offered in RFC5011 (which and is intended to complement the guidance offered in RFC5011 (which
is written to provide timing guidance solely to a Validating is written to provide timing guidance solely to a Validating
Resolver's point of view). Resolver's point of view).
To explain the RFC5011 security analysis in this document better,
Section 5 first describes an attack on a zone publisher. Then in
Section 6.1 we break down each of the timing components that will be
later used to define timing requirements for adding keys in
Section 6.2 and revoking keys in Section 6.3.
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 exclusively with a new KSK they must wait before signing a zone exclusively with a new KSK
[RFC4033] that was being introduced according to the 5011 process. [RFC4033] that was being introduced according to the 5011 process.
All 5 experts answered with an insecure value, and we determined that All 5 experts answered with an insecure value, and we determined that
this lack of mathematical understanding might cause security concerns this lack of mathematical understanding might cause security concerns
in deployment. We hope that this companion document to RFC5011 will in deployment. We hope that this companion document to RFC5011 will
rectify this understanding and provide better guidance to zone rectify this understanding and provide better guidance to zone
skipping to change at page 10, line 11 skipping to change at page 10, line 13
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.6. activeRefreshOffset 6.1.6. timingSafetyMargin
The activeRefreshOffset term must be added for situations where the Mentally, it is easy to assume that the period of time required for
activeRefresh value is not a factor of the addHoldDownTime. SEP publishers to wait after making changes to SEP marked DNSKEY sets
Specifically, activeRefreshOffset will be "addHoldDownTime % will be entirely based off the length of the addHoldDownTime.
activeRefresh", where % is the mathematical mod operator (calculating Unfortunately, analysis shows that both the design of the RFC5011
the remainder in a division problem). This will frequently be zero, protocol and in operational realities in deploying it require waiting
but could be nearly as large as activeRefresh itself. and additional period of time longer. In subsections Section 6.1.6.1
to Section 6.1.6.3 below, we discuss three sources of additional
delay. In the end, we will pick the largest of these delays as the
minimum additional time that the SEP Publisher must wait in our final
timingSafetyMargin value, which we define in Section 6.1.6.4.
Note that later (in Section 6.1.8), when real-world scenerios will 6.1.6.1. activeRefreshOffset
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.
6.1.7. driftSafetyMargin Security analysis of the timing associated with the query rate of
RFC5011 Resolvers shows that it may not perfectly align with the
addHoldDownTime when the addHoldDownTime is not evenly divisible by
the activeRefresh time. Consider the example of a zone with an
activeRefresh period of 7 days. If an associated RFC5011 Resolver
started it's holdDown timer just after the SEP published a new DNSKEY
(at time T), the resolver would send checking queries at T+7, T+14,
T+21 and T+28 Days and will finally accept it at T+35 days, which is
5 days longer than the 30-day addHoldDownTime.
Moving past the theoretical model parameters above, we not that clock The activeRefreshOffset term defines this time difference and
drift, network delays and implementation differences will result in becomes:
the RFC5011 Resolver query times to drift over time. Because of
this, a driftSafetyMargin term must be introduce that accounts for
these real world delays. We set this value to be the same as the
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 activeRefreshOffset = addHoldDownTime % activeRefresh
Resolvers to require up to an extra activeRefresh period before it
will accept a new DNSKEY as a trust anchor.
6.1.8. timingSafetyMargin The % symbol denotes the mathematical mod operator (calculating the
remainder in a division problem). This will frequently be zero, but
can be nearly as large as activeRefresh itself.
Both of the activeRefreshOffset and driftSafetyMargin parameters deal 6.1.6.2. clockskewDriftMargin
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: Even small clock drifts can have negative impacts upon the timing of
the RFC5011 Resolver's measurements. Consider the simplest case
where the RFC5011 Resolver's clock shifts over time to be 2 seconds
slower near the end of the RFC5011 Resolver's addHoldDownTime period.
I.E., if the RFC5011 Resolver first noticed a new DNSKEY at:
timingSafetyMargin = min(activeRefreshOffset, driftSafetyMargin) firstSeen = sigExpirationTime + activeRefresh + 1 second
timingSafetyMargin = min(addHoldDownTime % activeRefresh, The effect of 2 second clock drift between the SEP Publisher and the
RFC5011 Resolver may result in the RFC5011 Resolver querying again
at:
justBefore = sigExpirationTime + addHoldDownTime +
activeRefresh + 1 second - 2 seconds
which becomes:
justBefore = sigExpirationTime + addHoldDownTime +
activeRefresh - 1 second
The net effect is the addHoldDownTime will not have been reached from
the perspective of the RFC5011 Resolver, but it will have been
reached from the perspective of the SEP Publisher. The net effect is
it may take one additional activeRefresh period longer for this
RFC5011 Resolver to accept the new key (at sigExpirationTime +
addHoldDownTime + 2 * activeRefresh - 1 second).
We note that even the smallest clockskew errors can require waiting
an additional activeRefresh period, and thus define the
clockskewDriftMargin as:
clockskewDriftMargin = activeRefresh
6.1.6.3. retryDriftMargin
Drift associated with a lost transmission and an accompanying re-
transmission (see Section 2.3 of [RFC5011]) will cause RFC5011
Resolvers to also change the timing associated with query times such
that it becomes impossible to predict, from the perspective of the
PEP Publisher, when the final important measurement query will
arrive. Similarly, any software that restarts/reboots without saving
next-query timing state may also commence with a new random starting
time. Thus, an additional activeRefresh is needed to handle both
these cases as well.
retryDriftMargin = activeRefresh
Note that we account for additional time associated with cumulative
multiple retries, especially under high-loss conditions, in
Section 6.1.6.4.
6.1.6.4. timingSafetyMargin Value
The activeRefreshOffset, clockskewDriftMargin, and retryDriftMargin
parameters all deal with additional wait-periods that must be
accounted for after analyzing what conditions the client will take
longer than expected to make its last query while waiting for the
addHoldDownTime period to pass. But these values may be merged into
a single term by waiting the longest of any of them. We define
timingSafetyMargin as this "worst case" value:
timingSafetyMargin = MAX(activeRefreshOffset,
clockskewDriftMargin,
retryDriftMargin)
timingSafetyMargin = MAX(addWaitTime % activeRefresh,
activeRefresh,
activeRefresh) activeRefresh)
timingSafetyMargin = activeRefresh timingSafetyMargin = activeRefresh
6.1.9. retrySafetyMargin 6.1.7. retrySafetyMargin
The retrySafetyMargin is an extra period of time to account for The retrySafetyMargin is an extra period of time to account for
caching, network delays, dropped packets, and other operational caching, network delays, dropped packets, and other operational
concerns otherwise beyond the scope of this document. The value concerns otherwise beyond the scope of this document. The value
operators should chose is highly dependent on the deployment operators should chose is highly dependent on the deployment
situation associated with their zone. Note that no value of a situation associated with their zone. Note that no value of a
retrySafetyMargin can protect against resolvers that are "down". retrySafetyMargin can protect against resolvers that are "down".
None the less, we do offer the following as one method considering None the less, we do offer the following as one method considering
reasonable values to select from. reasonable values to select from.
skipping to change at page 12, line 29 skipping to change at page 13, line 42
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 retrySafetyMargin 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:
retrySafetyMargin = 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 Given the defined parameters and analysis from Section 6.1, we can
wait until it is safe to start signing exclusively with a new DNSKEY now create a method for calculating the amount of time to wait until
(especially useful for writing code involving sleep based timers), it is safe to start signing exclusively with a new DNSKEY (especially
and Section 6.2.2 defines a method for calculating a wall-clock value useful for writing code involving sleep based timers) in
Section 6.2.1, and define 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) in Section 6.2.2.
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
+ timingSafetyMargin + timingSafetyMargin
+ retrySafetyMargin + 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, + 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)
) )
+ activeRefresh
+ retrySafetyMargin + retrySafetyMargin
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
skipping to change at page 13, line 44 skipping to change at page 15, line 12
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)
) )
+ activeRefresh
+ retrySafetyMargin + retrySafetyMargin
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
skipping to change at page 17, line 26 skipping to change at page 18, line 43
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 retrySafetyMargin designed the suggested math behind the suggested retrySafetyMargin
values in Section 6.1.9. values in Section 6.1.7.
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, March 1997. Requirement Levels", BCP 14, RFC 2119,
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,
<http://www.rfc-editor.org/info/rfc4033>. <https://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, <https://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, <http://www.rfc-editor.org/info/rfc7719>. 2015, <https://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
 End of changes. 29 change blocks. 
76 lines changed or deleted 139 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/