< draft-ietf-dnsop-rfc5011-security-considerations-11.txt   draft-ietf-dnsop-rfc5011-security-considerations-12.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: August 5, 2018 February 01, 2018 Expires: September 24, 2018 March 23, 2018
Security Considerations for RFC5011 Publishers Security Considerations for RFC5011 Publishers
draft-ietf-dnsop-rfc5011-security-considerations-11 draft-ietf-dnsop-rfc5011-security-considerations-12
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 August 5, 2018. This Internet-Draft will expire on September 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
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 arrive at
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, To explain the RFC5011 security analysis in this document better,
Section 5 first describes an attack on a zone publisher. Then in 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 Section 6.1 we break down each of the timing components that will be
later used to define timing requirements for adding keys in later used to define timing requirements for adding keys in
Section 6.2 and revoking keys in Section 6.3. 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 confirm that this lack of understanding is wide-spread, the
reached out to 5 DNSSEC experts to ask them how long they thought authors reached out to 5 DNSSEC experts to ask them how long they
they must wait before signing a zone exclusively with a new KSK thought they must wait before signing a zone exclusively with a new
[RFC4033] that was being introduced according to the 5011 process. KSK [RFC4033] that was being introduced according to the 5011
All 5 experts answered with an insecure value, and we determined that process. All 5 experts answered with an insecure value, and we
this lack of mathematical understanding might cause security concerns determined that this lack of understanding might cause security
in deployment. We hope that this companion document to RFC5011 will concerns in deployment. We hope that this companion document to
rectify this understanding and provide better guidance to zone RFC5011 will rectify this and provide better guidance to zone
publishers that wish to make use of the RFC5011 rollover process. publishers who wish to make use of the RFC5011 rollover process.
1.2. Safely Rolling the Root Zone's KSK in 2017/2018 1.2. Safely Rolling the Root Zone's KSK in 2017/2018
One important note about ICANN's (currently in process) 2017/2018 KSK One important note about ICANN's (currently in process) 2017/2018 KSK
rollover plan for the root zone: the timing values chosen for rolling rollover plan for the root zone: the timing values chosen for rolling
the KSK in the root zone appear completely safe, and are not affected the KSK in the root zone appear completely safe, and are not affected
by the timing concerns introduced by this draft by the timing concerns discussed in 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 RFC5011 Resolver RFC5011 describes a process by which an RFC5011 Resolver may accept a
may accept a newly published KSK as a trust anchor for validating newly published KSK as a trust anchor for validating future DNSSEC
future DNSSEC signed records. It also describes the process for signed records. It also describes the process for publicly revoking
publicly revoking a published KSK. This document augments that a published KSK. This document augments that information with
information with additional constraints, from the SEP publisher's additional constraints, from the SEP publisher's points of view.
points of view. Note that this document does not define any other Note that this document does not define any other operational
operational guidance or recommendations about the RFC5011 process and guidance or recommendations about the RFC5011 process and restricts
restricts itself to solely the security and operational ramifications itself solely to the security and operational ramifications of
of switching to exclusively using recently added keys or removing prematurely switching to exclusively using recently added keys or
revoked keys too soon. removing revoked keys.
Failure of a DNSKEY publisher to follow the minimum recommendations Failure of a DNSKEY publisher to follow the minimum recommendations
associated with this draft can result in potential denial-of-service associated with this draft can result in potential denial-of-service
attack opportunities against validating resolvers. Failure of a attack opportunities against validating resolvers. Failure of a
DNSKEY publisher to publish a revoked key for a long enough period of DNSKEY publisher to publish a revoked key for a long enough period of
time may result in RFC5011 Resolvers leaving that key in their trust time may result in RFC5011 Resolvers leaving that key in their trust
anchor storage beyond the key's expected lifetime. anchor storage beyond the key's expected lifetime.
3. Terminology 3. Terminology
skipping to change at page 5, line 15 skipping to change at page 5, line 15
DNSKEY from its list of trust anchors. DNSKEY from its list of trust anchors.
sigExpirationTime The amount of time between the DNSKEY RRSIG's sigExpirationTime The amount of time between the DNSKEY RRSIG's
Signature Inception field and the Signature Expiration field. Signature Inception field and the Signature Expiration field.
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 subsections below give a high-level overview of [RFC5011]
These steps are not sufficient for proper RFC5011 implementation, but processing. This description is not sufficient for fully
provide enough background for the reader to follow the discussion in understanding RFC5011, but provide enough background for the reader
this document. Readers need to fully understand [RFC5011] as well to to follow the discussion in this document. Readers need to fully
fully comprehend the content and importance of this document. understand [RFC5011] as well to fully comprehend the content and
importance of this document.
4.1. Timing Associated with Publication 4.1. Timing Associated with Publication
RFC5011's process of safely publishing a new DNSKEY and then assuming RFC5011's process of safely publishing a new DNSKEY and then assuming
RFC5011 Resolvers have adopted it for trust falls into a number of RFC5011 Resolvers have adopted it for trust can be broken down into a
high-level steps to be performed by the SEP Publisher. This document number of high-level steps to be performed by the SEP Publisher.
discusses the following scenario, which the principle way RFC5011 is This document discusses the following scenario, which the principal
currently being used (even though Section 6 of RFC5011 suggests way RFC5011 is currently being used (even though Section 6 of RFC5011
having a stand-by key available): suggests having a stand-by key available):
1. Publish a new DNSKEY in a zone, but continue to sign the zone 1. Publish a new DNSKEY in a 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 the time required to wait during step 2 of This document discusses the time required to wait during step 2 of
skipping to change at page 6, line 29 skipping to change at page 6, line 29
This section serves as an illustrative example of the problem being This section serves as an illustrative example of the problem being
discussed in this document. Note that in order to keep the example discussed in this document. Note that in order to keep the example
simple enough to understand, some simplifications were made (such as simple enough to understand, some simplifications were made (such as
by not creating a set of pre-signed RRSIGs and by not using values by not creating a set of pre-signed RRSIGs and by not using values
that result in the addHoldDownTime not being evenly divisible by the that result in the addHoldDownTime not being evenly divisible by the
activeRefresh value); the mathematical formulas in Section 6 are, activeRefresh value); the mathematical formulas in Section 6 are,
however, complete. however, complete.
If an attacker is able to provide a RFC5011 Resolver with past If an attacker is able to provide a RFC5011 Resolver with past
responses, such as when it is in-path or able to perform any number responses, such as when it is on-path or able to perform any number
of cache poisoning attacks, the attacker may be able to leave of cache poisoning attacks, the attacker may be able to leave
compliant RFC5011 Resolvers without an appropriate DNSKEY trust compliant RFC5011 Resolvers without an appropriate DNSKEY trust
anchor. This scenario will remain until an administrator manually anchor. This scenario will remain until an administrator manually
fixes the situation. fixes the situation.
The time-line below illustrates an example of this situation. The time-line below illustrates an example of this situation.
5.1. Enumerated Attack Example 5.1. Enumerated Attack Example
The following example settings are used in the example scenario The following settings are used in the example scenario within this
within this section: section:
TTL (all records) 1 day TTL (all records) 1 day
sigExpirationTime 10 days sigExpirationTime 10 days
Zone resigned every 1 day Zone resigned every 1 day
Given these settings, the sequence of events in Section 5.1.1 depicts Given these settings, the sequence of events in Section 5.1.1 depicts
how a SEP Publisher that waits for only the RFC5011 hold time timer how a SEP Publisher that waits for only the RFC5011 hold time timer
length of 30 days subjects its users to a potential Denial of Service length of 30 days subjects its users to a potential Denial of Service
attack. The timing schedule listed below is based on a SEP Publisher attack. The timeline below is based on a SEP Publisher publishing a
publishing a new Key Signing Key (KSK), with the intent that it will new Key Signing Key (KSK), with the intent that it will later be used
later be used as a trust anchor. We label this publication time as as a trust anchor. We label this publication time as "T+0". All
"T+0". All numbers in this sequence refer to days before and after numbers in this timeline refer to days before and after this initial
this initial publication event. Thus, T-1 is the day before the publication event. Thus, T-1 is the day before the introduction of
introduction of the new key, and T+15 is the 15th day after the key the new key, and T+15 is the 15th day after the key was introduced
was introduced into the fictitious zone being discussed. into the example zone being discussed.
In this dialog, we consider two keys within the example zone: In this exposition, we consider two keys within the example zone:
K_old: An older KSK and Trust Anchor being replaced. K_old: An older KSK and Trust Anchor being replaced.
K_new: A new KSK being transitioned into active use and expected to K_new: A new KSK being transitioned into active use and expected to
become a Trust Anchor via the RFC5011 automated trust anchor become a Trust Anchor via the RFC5011 automated trust anchor
update process. update process.
5.1.1. Attack Timing Breakdown 5.1.1. Attack Timing Breakdown
The steps shows an attack that foils the adoption of a new DNSKEY by Below we examine an attack that foils the adoption of a new DNSKEY by
a 5011 Resolver when the SEP Publisher that starts signing and a 5011 Resolver when the SEP Publisher that starts signing and
publishing with the new DNSKEY too quickly. 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.
skipping to change at page 9, line 7 skipping to change at page 9, line 7
6. Minimum RFC5011 Timing Requirements 6. Minimum RFC5011 Timing Requirements
This section defines the minimum timing requirements for making This section defines the minimum timing requirements for making
exclusive use of newly added DNSKEYs and timing requirements for exclusive use of newly added DNSKEYs and timing requirements for
ceasing the publication of DNSKEYs to be revoked. We break our ceasing the publication of DNSKEYs to be revoked. We break our
timing solution requirements into two primary components: the timing solution requirements into two primary components: the
mathematically-based security analysis of the RFC5011 publication mathematically-based security analysis of the RFC5011 publication
process itself, and an extension of this that takes operational process itself, and an extension of this that takes operational
realities into account that further affect the recommended timings. realities into account that further affect the recommended timings.
First, we define the term components used in all equations in First, we define the component terms used in all equations in
Section 6.1. Section 6.1.
6.1. Equation Components 6.1. Equation Components
6.1.1. addHoldDownTime 6.1.1. addHoldDownTime
The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as: The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as:
The add hold-down time is 30 days or the expiration time of the The add hold-down time is 30 days or the expiration time of the
original TTL of the first trust point DNSKEY RRSet that contained original TTL of the first trust point DNSKEY RRSet that contained
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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. timingSafetyMargin 6.1.6. timingSafetyMargin
Mentally, it is easy to assume that the period of time required for Mentally, it is easy to assume that the period of time required for
SEP publishers to wait after making changes to SEP marked DNSKEY sets SEP publishers to wait after making changes to SEP marked DNSKEY sets
will be entirely based off the length of the addHoldDownTime. will be entirely based on the length of the addHoldDownTime.
Unfortunately, analysis shows that both the design of the RFC5011 Unfortunately, analysis shows that both the design of the RFC5011
protocol and in operational realities in deploying it require waiting protocol an the operational realities in deploying it require waiting
and additional period of time longer. In subsections Section 6.1.6.1 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 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 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 minimum additional time that the SEP Publisher must wait in our final
timingSafetyMargin value, which we define in Section 6.1.6.4. timingSafetyMargin value, which we define in Section 6.1.6.4.
6.1.6.1. activeRefreshOffset 6.1.6.1. activeRefreshOffset
Security analysis of the timing associated with the query rate of A security analysis of the timing associated with the query rate of
RFC5011 Resolvers shows that it may not perfectly align with the RFC5011 Resolvers shows that it may not perfectly align with the
addHoldDownTime when the addHoldDownTime is not evenly divisible by addHoldDownTime when the addHoldDownTime is not evenly divisible by
the activeRefresh time. Consider the example of a zone with an the activeRefresh time. Consider the example of a zone with an
activeRefresh period of 7 days. If an associated RFC5011 Resolver activeRefresh period of 7 days. If an associated RFC5011 Resolver
started it's holdDown timer just after the SEP published a new DNSKEY 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, (at time T+0), 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 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. 5 days longer than the 30-day addHoldDownTime.
The activeRefreshOffset term defines this time difference and The activeRefreshOffset term defines this time difference and
becomes: becomes:
activeRefreshOffset = addHoldDownTime % activeRefresh activeRefreshOffset = addHoldDownTime % activeRefresh
The % symbol denotes the mathematical mod operator (calculating the The % symbol denotes the mathematical mod operator (calculating the
remainder in a division problem). This will frequently be zero, but remainder in a division problem). This will frequently be zero, but
skipping to change at page 11, line 40 skipping to change at page 11, line 40
clockskewDriftMargin as: clockskewDriftMargin as:
clockskewDriftMargin = activeRefresh clockskewDriftMargin = activeRefresh
6.1.6.3. retryDriftMargin 6.1.6.3. retryDriftMargin
Drift associated with a lost transmission and an accompanying re- Drift associated with a lost transmission and an accompanying re-
transmission (see Section 2.3 of [RFC5011]) will cause RFC5011 transmission (see Section 2.3 of [RFC5011]) will cause RFC5011
Resolvers to also change the timing associated with query times such Resolvers to also change the timing associated with query times such
that it becomes impossible to predict, from the perspective of the that it becomes impossible to predict, from the perspective of the
PEP Publisher, when the final important measurement query will SEP Publisher, when the conclusive measurement query will arrive.
arrive. Similarly, any software that restarts/reboots without saving Similarly, any software that restarts/reboots without saving next-
next-query timing state may also commence with a new random starting query timing state may also commence with a new random starting time.
time. Thus, an additional activeRefresh is needed to handle both Thus, an additional activeRefresh is needed to handle both these
these cases as well. cases as well.
retryDriftMargin = activeRefresh retryDriftMargin = activeRefresh
Note that we account for additional time associated with cumulative Note that we account for additional time associated with cumulative
multiple retries, especially under high-loss conditions, in multiple retries, especially under high-loss conditions, in
Section 6.1.6.4. Section 6.1.6.4.
6.1.6.4. timingSafetyMargin Value 6.1.6.4. timingSafetyMargin Value
The activeRefreshOffset, clockskewDriftMargin, and retryDriftMargin The activeRefreshOffset, clockskewDriftMargin, and retryDriftMargin
skipping to change at page 12, line 33 skipping to change at page 12, line 33
timingSafetyMargin = activeRefresh timingSafetyMargin = activeRefresh
6.1.7. 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 Nonetheless, we do offer the following as one method considering
reasonable values to select from. reasonable values to select from.
The following list of variables need to be considered when selecting The following list of variables need to be considered when selecting
an appropriate retrySafetyMargin value: an appropriate retrySafetyMargin value:
successRate: A likely success rate for client queries and retries successRate: A likely success rate for client queries and retries
numResolvers: The number of client RFC5011 Resolvers numResolvers: The number of client RFC5011 Resolvers
Note that RFC5011 defines retryTime as: Note that RFC5011 defines retryTime as:
skipping to change at page 13, line 8 skipping to change at page 13, line 8
If the query fails, the resolver MUST repeat the query until If the query fails, the resolver MUST repeat the query until
satisfied no more often than once an hour and no less often satisfied no more often than once an hour and no less often
than the lesser of 1 day, 10% of the original TTL, or 10% of than the lesser of 1 day, 10% of the original TTL, or 10% of
the original expiration interval. That is, the original expiration interval. That is,
retryTime = MAX (1 hour, MIN (1 day, .1 * origTTL, retryTime = MAX (1 hour, MIN (1 day, .1 * origTTL,
.1 * expireInterval)). .1 * expireInterval)).
With the successRate and numResolvers values selected and the With the successRate and numResolvers values selected and the
definition of retryTime from RFC5011, one method for determining how definition of retryTime from RFC5011, one method for determining how
many retryTime intervals to wait in order to reduce the set of many retryTime intervals to wait in order to reduce the set of
uncompleted servers to 0 assuming normal probability is thus: resolvers that have not accepted the new trust anchor to 0 is thus:
x = (1/(1 - successRate)) x = (1/(1 - successRate))
retryCountWait = Log_base_x(numResolvers) retryCountWait = Log_base_x(numResolvers)
To reduce the need for readers to pull out a scientific calculator, To reduce the need for readers to pull out a scientific calculator,
we offer the following lookup table based on successRate and we offer the following lookup table based on successRate and
numResolvers: numResolvers:
retryCountWait lookup table retryCountWait lookup table
skipping to change at page 19, line 8 skipping to change at page 19, line 8
designed the suggested math behind the suggested retrySafetyMargin designed the suggested math behind the suggested retrySafetyMargin
values in Section 6.1.7. 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, Requirement Levels", BCP 14, RFC 2119, March 1997.
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,
<https://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, <https://www.rfc-editor.org/info/rfc5011>. September 2007, <http://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, <https://www.rfc-editor.org/info/rfc7719>. 2015, <http://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. 26 change blocks. 
64 lines changed or deleted 63 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/