idnits 2.17.1 draft-ietf-dnsop-rfc5011-security-considerations-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7583, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2017) is 2389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7583 ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop W. Hardaker 3 Internet-Draft USC/ISI 4 Updates: 7583 (if approved) W. Kumari 5 Intended status: Standards Track Google 6 Expires: March 17, 2018 September 13, 2017 8 Security Considerations for RFC5011 Publishers 9 draft-ietf-dnsop-rfc5011-security-considerations-04 11 Abstract 13 This document extends the RFC5011 rollover strategy with timing 14 advice that must be followed in order to maintain security. 15 Specifically, this document describes the math behind the minimum 16 time-length that a DNS zone publisher must wait before signing 17 exclusively with recently added DNSKEYs. It contains much math and 18 complicated equations, but the summary is that the key rollover / 19 revocation time is much longer than intuition would suggest. If you 20 are not both publishing a DNSSEC trust anchor, and using RFC5011 to 21 update that trust anchor, you probably don't need to read this 22 document. 24 This document also describes the minimum time-length that a DNS zone 25 publisher must wait after publishing a revoked DNSKEY before assuming 26 that all active RFC5011 resolvers should have seen the revocation- 27 marked key and removed it from their list of trust anchors. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 17, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Document History and Motivation . . . . . . . . . . . . . 3 65 1.2. Safely Rolling the Root Zone's KSK in 2017/2018 . . . . . 3 66 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 3 67 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Timing Associated with RFC5011 Processing . . . . . . . . . . 4 70 4.1. Timing Associated with Publication . . . . . . . . . . . 5 71 4.2. Timing Associated with Revocation . . . . . . . . . . . . 5 72 5. Denial of Service Attack Considerations . . . . . . . . . . . 5 73 5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6 74 5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6 75 6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8 76 6.1. Timing Requirements For Adding a New KSK . . . . . . . . 8 77 6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 8 78 6.1.2. sigExpirationTime . . . . . . . . . . . . . . . . . . 8 79 6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 8 80 6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9 81 6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 9 82 6.1.6. Fully expanded equation . . . . . . . . . . . . . . . 9 83 6.1.7. Timing Constraint Summary . . . . . . . . . . . . . . 10 84 6.1.8. Additional Considerations . . . . . . . . . . . . . . 10 85 6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 11 86 6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 11 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 8. Operational Considerations . . . . . . . . . . . . . . . . . 12 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 91 11. Normative References . . . . . . . . . . . . . . . . . . . . 13 92 Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 13 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 [RFC5011] defines a mechanism by which DNSSEC validators can update 98 their list of trust anchors when they've seen a new key published in 99 a zone. However, RFC5011 [intentionally] provides no guidance to the 100 publishers of DNSKEYs about how long they must wait before switching 101 to exclusively using recently published keys for signing records, or 102 how long they must wait before ceasing publication of a revoked key. 103 Because of this lack of guidance, zone publishers may derive 104 incorrect assumptions about safe usage of the RFC5011 DNSKEY 105 advertising, rolling and revocation process. This document describes 106 the minimum security requirements from a publisher's point of view 107 and is intended to complement the guidance offered in RFC5011 (which 108 is written to provide timing guidance solely to a Validating 109 Resolver's point of view). 111 1.1. Document History and Motivation 113 To verify this lack of understanding is wide-spread, the authors 114 reached out to 5 DNSSEC experts to ask them how long they thought 115 they must wait before signing a zone exclusively with a new KSK 116 [RFC4033] that was being introduced according to the 5011 process. 117 All 5 experts answered with an insecure value, and we determined that 118 this lack of operational guidance is causing security concerns today 119 and wrote this companion document to RFC5011. We hope that this 120 document will rectify this understanding and provide better guidance 121 to zone publishers that wish to make use of the RFC5011 rollover 122 process. 124 1.2. Safely Rolling the Root Zone's KSK in 2017/2018 126 One important note about ICANN's [currently upcoming] 2017/2018 KSK 127 rollover plan for the root zone: the timing values chosen for rolling 128 the KSK in the root zone appear completely safe, and are not affected 129 by the timing concerns introduced by this draft 131 1.3. Requirements notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. Background 139 The RFC5011 process describes a process by which a RFC5011 Validating 140 Resolver may accept a newly published KSK as a trust anchor for 141 validating future DNSSEC signed records. It also describes the 142 process for publicly revoking a published KSK. This document 143 augments that information with additional constraints, from the 144 DNSKEY publication and revocation's points of view. Note that this 145 document does not define any other operational guidance or 146 recommendations about the RFC5011 process and restricts itself to 147 solely the security and operational ramifications of switching to 148 exclusively using recently added keys or removing a revoked keys too 149 soon. 151 Failure of a DNSKEY publisher to follow the minimum recommendations 152 associated with this draft will result in potential denial-of-service 153 attack opportunities against validating resolvers. Failure of a 154 DNSKEY publisher to publish a revoked key for a long enough period of 155 time may result in RFC5011 Validating Resolvers leaving that key in 156 their trust anchor storage beyond the key's expected lifetime. 158 3. Terminology 160 Trust Anchor Publisher The entity responsible for publishing a 161 DNSKEY that can be used as a trust anchor. 163 Zone Signer The owner of a zone intending to publish a new Key- 164 Signing-Key (KSK) that will become a trust anchor by validators 165 following the RFC5011 process. 167 RFC5011 Validating Resolver A DNSSEC Validating Resolver that is 168 using the RFC5011 processes to track and update trust anchors. 169 Sometimes referred to as a "RFC5011 Resolver" 171 Attacker An entity intent on foiling the RFC5011 Validator's ability 172 to successfully adopt the Zone Signer's new DNSKEY as a new trust 173 anchor or to prevent the RFC5011 Validator from removing an old 174 DNSKEY from its list of trust anchors. 176 sigExpirationTime The amount of time remaining before a RRSIG's 177 Signature Expiration time is reached. This will fundamentally be 178 the RRSIG's Signature Expiration time minus the RRSIG's Signature 179 Inception time when the signature is created. 181 Also see Section 2 of [RFC4033] and [RFC7719] for additional 182 terminology. 184 4. Timing Associated with RFC5011 Processing 186 These sections define a high-level overview of [RFC5011] processing. 187 These steps are not sufficient for proper RFC5011 implementation, but 188 provide enough background for the reader to follow the discussion in 189 this document. Readers need to fully understand [RFC5011] as well to 190 fully comprehend the importance of this document. 192 4.1. Timing Associated with Publication 194 RFC5011's process of safely publishing a new key and then making use 195 of that key falls into a number of high-level steps to be performed 196 by the Trust Anchor Publisher. This document discusses the following 197 scenario, which is one of many possible combinations of operations 198 defined in Section 6 of RFC5011: 200 1. Publish a new DNSKEY in the zone, but continue to sign the zone 201 with the old one. 203 2. Wait a period of time. 205 3. Begin to exclusively use recently published DNSKEYs to sign the 206 appropriate resource records. 208 This document discusses step 2 of the above process. Some 209 interpretations of RFC5011 have erroneously determined that the wait 210 time is equal to RFC5011's "hold down time". Section 5 describes an 211 attack based on this (common) erroneous belief, which can result in a 212 denial of service attack against the zone. 214 4.2. Timing Associated with Revocation 216 RFC5011's process of advertising that an old key is to be revoked 217 from RFC5011 validating resolvers falls into a number of high-level 218 steps: 220 1. Set the revoke bit on the DNSKEY to be revoked. 222 2. Sign the revoked DNSKEY with itself. 224 3. Wait a period of time. 226 4. Remove the revoked key from the zone. 228 This document discusses step 3 of the above process. Some 229 interpretations of RFC5011 have erroneously determined that the wait 230 time is equal to RFC5011's "hold down time". This document describes 231 an attack based on this (common) erroneous belief, which results in a 232 revoked DNSKEY potentially remaining as a trust anchor in a RFC5011 233 validating resolver long past its expected usage. 235 5. Denial of Service Attack Considerations 237 If an attacker is able to provide a RFC5011 Validating Resolver with 238 past responses, such as when it is in-path or able to perform any 239 number of cache poisoning attacks, the attacker may be able to leave 240 compliant RFC5011-Validating Resolvers without an appropriate DNSKEY 241 trust anchor. This scenario will remain until an administrator 242 manually fixes the situation. 244 The time-line below illustrates this situation. 246 5.1. Enumerated Attack Example 248 The following example settings are used in the example scenario 249 within this section: 251 TTL (all records) 1 day 253 sigExpirationTime 10 days 255 Zone resigned every 1 day 257 Given these settings, the sequence of events in Section 5.1.1 depicts 258 how a Trust Anchor Publisher that waits for only the RFC5011 hold 259 time timer length of 30 days subjects its users to a potential Denial 260 of Service attack. The timing schedule listed below is based on a 261 Trust Anchor Publisher publishing a new Key Signing Key (KSK), with 262 the intent that it will later become a trust anchor. We label this 263 publication time as "T+0". All numbers in this sequence refer to 264 days before and after this initial publication event. Thus, T-1 is 265 the day before the introduction of the new key, and T+15 is the 15th 266 day after the key was introduced into the fictitious zone being 267 discussed. 269 In this dialog, we consider two keys within the example zone: 271 K_old An older KSK and Trust Anchor being replaced. 273 K_new A new KSK being transitioned into active use and expected to 274 become a Trust Anchor via the RFC5011 process. 276 5.1.1. Attack Timing Breakdown 278 The steps shows an attack that foils the adoption of a new DNSKEY by 279 a 5011 Validating Resolver when the Trust Anchor Publisher that 280 starts signing and publishing with the new DNSKEY too quickly. 282 T-1 The K_old based RRSIGs are being published by the Zone Signer. 283 [It may also be signing ZSKs as well, but they are not relevant to 284 this event so we will not talk further about them; we are only 285 considering the RRSIGs that cover the DNSKEYs in this document.] 286 The Attacker queries for, retrieves and caches this DNSKEY set and 287 corresponding RRSIG signatures. 289 T+0 The Zone Signer adds K_new to their zone and signs the zone's 290 key set with K_old. The RFC5011 Validator (later to be under 291 attack) retrieves this new key set and corresponding RRSIGs and 292 notices the publication of K_new. The RFC5011 Validator starts 293 the (30-day) hold-down timer for K_new. [Note that in a more 294 real-world scenario there will likely be a further delay between 295 the point where the Zone Signer publishes a new RRSIG and the 296 RFC5011 Validator notices its publication; though not shown in 297 this example, this delay is accounted for in the final solution 298 below] 300 T+5 The RFC5011 Validator queries for the zone's keyset per the 301 RFC5011 Active Refresh schedule, discussed in Section 2.3 of 302 RFC5011. Instead of receiving the intended published keyset, the 303 Attacker successfully replays the keyset and associated signatures 304 recorded at T-1. Because the signature lifetime is 10 days (in 305 this example), the replayed signature and keyset is accepted as 306 valid (being only 6 days old, which is less than 307 sigExpirationTime) and the RFC5011 Validator cancels the hold-down 308 timer for K_new, per the RFC5011 algorithm. 310 T+10 The RFC5011 Validator queries for the zone's keyset and 311 discovers a signed keyset that includes K_new (again), and is 312 signed by K_old. Note: the attacker is unable to replay the 313 records cached at T-1, because they have now expired. Thus at 314 T+10, the RFC5011 Validator starts (anew) the hold-timer for 315 K_new. 317 T+11 through T+29 The RFC5011 Validator continues checking the 318 zone's key set at the prescribed regular intervals. During this 319 period, the attacker can no longer replay traffic to their 320 benefit. 322 T+30 The Zone Signer knows that this is the first time at which some 323 validators might accept K_new as a new trust anchor, since the 324 hold-down timer of a RFC5011 Validator not under attack that had 325 queried and retrieved K_new at T+0 would now have reached 30 days. 326 However, the hold-down timer of our attacked RFC5011 Validator is 327 only at 20 days. 329 T+35 The Zone Signer (mistakenly) believes that all validators 330 following the Active Refresh schedule (Section 2.3 of RFC5011) 331 should have accepted K_new as a the new trust anchor (since the 332 hold down time (30 days) + the query interval [which is just 1/2 333 the signature validity period in this example] would have passed). 334 However, the hold-down timer of our attacked RFC5011 Validator is 335 only at 25 days (T+35 minus T+10); thus the RFC5011 won't consider 336 it a valid trust anchor addition yet, as the required 30 days have 337 not yet elapsed. 339 T+36 The Zone Signer, believing K_new is safe to use, switches their 340 active signing KSK to K_new and publishes a new RRSIG, signed with 341 K_new, covering the DNSKEY set. Non-attacked RFC5011 validators, 342 with a hold-down timer of at least 30 days, would have accepted 343 K_new into their set of trusted keys. But, because our attacked 344 RFC5011 Validator now has a hold-down timer for K_new of only 26 345 days, it failed to accept K_new as a trust anchor. Since K_old is 346 no longer being used to sign the zone's DNSKEYs, all the DNSKEY 347 records from the zone will be treated as invalid. Subsequently, 348 all of the records in the DNS tree below the zone's apex will be 349 deemed invalid by DNSSEC. 351 6. Minimum RFC5011 Timing Requirements 353 6.1. Timing Requirements For Adding a New KSK 355 Given the attack description in Section 5, the correct minimum length 356 of time required for the Zone Signer to wait after publishing K_new 357 but before exclusively using it and newer keys is: 359 addWaitTime = addHoldDownTime 360 + sigExpirationTime 361 + activeRefresh 362 + activeRefreshOffset 363 + safetyMargin 365 6.1.1. addHoldDownTime 367 The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as: 369 The add hold-down time is 30 days or the expiration time of the 370 original TTL of the first trust point DNSKEY RRSet that contained 371 the new key, whichever is greater. This ensures that at least 372 two validated DNSKEY RRSets that contain the new key MUST be seen 373 by the resolver prior to the key's acceptance. 375 6.1.2. sigExpirationTime 377 sigExpirationTime is defined in Section 3. 379 6.1.3. activeRefresh 381 activeRefresh time is defined by RFC5011 by 382 A resolver that has been configured for an automatic update 383 of keys from a particular trust point MUST query that trust 384 point (e.g., do a lookup for the DNSKEY RRSet and related 385 RRSIG records) no less often than the lesser of 15 days, half 386 the original TTL for the DNSKEY RRSet, or half the RRSIG 387 expiration interval and no more often than once per hour. 389 This translates to: 391 activeRefresh = MAX(1 hour, 392 MIN(sigExpirationTime / 2, 393 MAX(TTL of K_old DNSKEY RRSet) / 2, 394 15 days) 395 ) 397 6.1.4. activeRefreshOffset 399 The activeRefreshOffset term must be added for situations where the 400 activeRefresh value is not a factor of "30 days". Specifically, 401 activeRefreshOffset will be "(30 days) % activeRefresh", where % is 402 the mathematical mod operator (which calculates the remainder in a 403 division problem). This will frequently be zero, but could be nearly 404 as large as activeRefresh itself. For simplicity, setting the 405 activeRefreshOffset to the activeRefresh value itself is safe. 407 6.1.5. safetyMargin 409 The safetyMargin is an extra period of time to account for caching, 410 network delays, etc. A suggested operational value for this is 2 * 411 MAX(TTL of all records) 413 RFC5011 also discusses a retryTime value for failed queries. Our 414 equation cannot take into account undeterministic failure situations, 415 so it might be wise to extend the safetyMargin by some factor of 416 retryTime, which is defined in RFC5011 as: 418 retryTime = MAX (1 hour, 419 MIN (1 day, 420 .1 * TTL of K_old DNSKEY RRset, 421 .1 * sigExpirationTime)) 423 6.1.6. Fully expanded equation 425 The full expanded equation, with activeRefreshOffset set to 426 activeRefresh for simplicity, is: 428 addWaitTime = addHoldDownTime 429 + sigExpirationTime 430 + 2 * MAX(1 hour, 431 MIN(sigExpirationTime / 2, 432 MAX(TTL of K_old DNSKEY RRSet) / 2, 433 15 days) 434 ) 435 + 2 * MAX(TTL of all records) 437 6.1.7. Timing Constraint Summary 439 The important timing constraint introduced by this memo relates to 440 the last point at which a validating resolver may have received a 441 replayed original DNSKEY set, containing K_old and not K_new. The 442 next query of the RFC5011 validator at which K_new will be seen 443 without the potential for a replay attack will occur after the 444 publication time plus sigExpirationTime. Thus, the latest time that 445 a RFC5011 Validator may begin their hold down timer is an "Active 446 Refresh" period after the last point that an attacker can replay the 447 K_old DNSKEY set. The worst case scenario of this attack is if the 448 attacker can replay K_old seconds before the (DNSKEY RRSIG Signature 449 Validity) field of the last K_old only RRSIG. 451 6.1.8. Additional Considerations 453 Note: our notion of addWaitTime is called "Itrp" in Section 3.3.4.1 454 of [RFC7583]. The equation for Itrp in RFC7583 is insecure as it 455 does not include the sigExpirationTime listed above. The Itrp 456 equation in RFC7583 also does not include the 2*TTL safety margin, 457 though that is an operational consideration and not necessarily as 458 critical. 460 6.1.8.1. Example Results 462 For the parameters listed in Section 5.1, the activeRefreshOffset is 463 0, since 30 days is evenly divisible by activeRefresh (1/2 day), and 464 our resulting addWaitTime is: 466 addWaitTime = 30 467 + 10 468 + 1 / 2 469 + 2 * (1) (days) 471 addWaitTime = 42.5 (days) 473 This addWaitTime of 42.5 days is 12.5 days longer than just the hold 474 down timer. 476 6.2. Timing Requirements For Revoking an Old KSK 478 It is important to note that this issue affects not just the 479 publication of new DNSKEYs intended to be used as trust anchors, but 480 also the length of time required to continuously publish a DNSKEY 481 with the revoke bit set. Both of these publication timing 482 requirements are affected by the attacks described in this document, 483 but with revocation the key is revoked immediately and the 484 addHoldDown timer does not apply. Thus the minimum amount of time 485 that a Trust Anchor Publisher must wait before removing a revoked key 486 from publication is: 488 remWaitTime = sigExpirationTime 489 + MAX(1 hour, 490 MIN((sigExpirationTime) / 2, 491 MAX(TTL of K_old DNSKEY RRSet) / 2, 492 15 days), 493 1 hour) 494 + 2 * MAX(TTL of all records) 496 Note that the activeRefreshOffset time does not apply to this 497 equation. 499 Note that our notion of remWaitTime is called "Irev" in 500 Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is 501 insecure as it does not include the sigExpirationTime listed above. 502 The Irev equation in RFC7583 also does not include the 2*TTL safety 503 margin, though that is an operational consideration and not 504 necessarily as critical. 506 Note also that adding retryTime intervals to the remWaitTime may be 507 wise, just as it was for addWaitTime in Section 6. 509 6.2.1. Example Results 511 For the parameters listed in Section 5.1, our example: 513 remwaitTime = 10 514 + 1 / 2 515 + 2 * (1) (days) 517 remwaitTime = 12.5 (days) 519 Note that for the values in this example produce a length shorter 520 than the recommended 30 days in RFC5011's section 6.6, step 3. Other 521 values of sigExpirationTime and the original TTL of the K_old DNSKEY 522 RRSet, however, can produce values longer than 30 days. 524 Note that because revocation happens immediately, an attacker has a 525 much harder job tricking a RFC5011 Validator into leaving a trust 526 anchor in place, as the attacker must successfully replay the old 527 data for every query a RFC5011 Validator sends, not just one. 529 7. IANA Considerations 531 This document contains no IANA considerations. 533 8. Operational Considerations 535 A companion document to RFC5011 was expected to be published that 536 describes the best operational practice considerations from the 537 perspective of a zone publisher and Trust Anchor Publisher. However, 538 this companion document has yet to be published. The authors of this 539 document hope that it will at some point in the future, as RFC5011 540 timing can be tricky as we have shown, and a BCP is clearly 541 warranted. This document is intended only to fill a single 542 operational void which, when left misunderstood, can result in 543 serious security ramifications. This document does not attempt to 544 document any other missing operational guidance for zone publishers. 546 9. Security Considerations 548 This document, is solely about the security considerations with 549 respect to the Trust Anchor Publisher of RFC5011 trust anchors / 550 DNSKEYs. Thus the entire document is a discussion of Security 551 Considerations when adding or removing DNSKEYs from trust anchor 552 storage using the RFC5011 process. 554 For simplicity, this document assumes that the Trust Anchor Publisher 555 will use a consistent RRSIG validity period. Trust Anchor Publishers 556 that vary the length of RRSIG validity periods will need to adjust 557 the sigExpirationTime value accordingly so that the equations in 558 Section 6 and Section 6.2 use a value that coincides with the last 559 time a replay of older RRSIGs will no longer succeed. 561 10. Acknowledgements 563 The authors would like to especially thank to Michael StJohns for his 564 help and advice and the care and thought he put into RFC5011 itself. 565 We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking, 566 Duane Wessels, Petr Petr Spacek, Ed Lewis, and the dnsop working 567 group who have assisted with this document. 569 11. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 575 Rose, "DNS Security Introduction and Requirements", 576 RFC 4033, DOI 10.17487/RFC4033, March 2005, 577 . 579 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 580 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 581 September 2007, . 583 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 584 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 585 DOI 10.17487/RFC7583, October 2015, . 588 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 589 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 590 2015, . 592 Appendix A. Real World Example: The 2017 Root KSK Key Roll 594 In 2017, ICANN expects to (or has, depending on when you're reading 595 this) roll the key signing key (KSK) for the root zone. The relevant 596 parameters associated with the root zone at the time of this writing 597 is as follows: 599 addHoldDownTime: 30 days 600 Old DNSKEY sigExpirationTime: 21 days 601 Old DNSKEY TTL: 2 days 603 Thus, sticking this information into the equation in 604 Section Section 6 yields (in days): 606 addWaitTime = 30 607 + (21) 608 + MAX(MIN((21) / 2, 609 MAX(2 / 2, 610 15 days)), 611 1 hour) 612 + 2 * MAX(2) 614 addWaitTime = 30 + 21 + MAX(MIN(11.5, 1, 15)), 1 hour) + 4 616 addWaitTime = 30 + 21 + 1 + 4 618 addWaitTime = 56 days 620 Note that we use a activeRefreshOffset of 0, since 30 days is evenly 621 divisible by activeRefresh (1 day). 623 Thus, ICANN should wait a minimum of 56 days before switching to the 624 newly published KSK (and 26 days before removing the old revoked key 625 once it is published as revoked). ICANN's current plans are to wait 626 70 days before using the new KEY and 69 days before removing the old, 627 revoked key. Thus, their current rollover plans are sufficiently 628 secure from the attack discussed in this memo. 630 Authors' Addresses 632 Wes Hardaker 633 USC/ISI 634 P.O. Box 382 635 Davis, CA 95617 636 US 638 Email: ietf@hardakers.net 640 Warren Kumari 641 Google 642 1600 Amphitheatre Parkway 643 Mountain View, CA 94043 644 US 646 Email: warren@kumari.net