idnits 2.17.1 draft-ietf-dnsop-rfc5011-security-considerations-03.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 12, 2017) is 2411 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 16, 2018 September 12, 2017 8 Security Considerations for RFC5011 Publishers 9 draft-ietf-dnsop-rfc5011-security-considerations-03 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. This document also 18 describes the minimum time-length that a DNS zone publisher must wait 19 after publishing a revoked DNSKEY before assuming that all active 20 RFC5011 resolvers should have seen the revocation-marked key and 21 removed it from their list of trust anchors. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 16, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Document History and Motivation . . . . . . . . . . . . . 3 59 1.2. Safely Rolling the Root Zone's KSK in 2017/2018 . . . . . 3 60 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 3 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Timing Associated with RFC5011 Processing . . . . . . . . . . 4 64 4.1. Timing Associated with Publication . . . . . . . . . . . 4 65 4.2. Timing Associated with Revocation . . . . . . . . . . . . 5 66 5. Denial of Service Attack Considerations . . . . . . . . . . . 5 67 5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 5 68 5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6 69 6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8 70 6.1. Timing Requirements For Adding a New KSK . . . . . . . . 8 71 6.1.1. Example Results . . . . . . . . . . . . . . . . . . . 10 72 6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 10 73 6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Operational Considerations . . . . . . . . . . . . . . . . . 11 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 [RFC5011] defines a mechanism by which DNSSEC validators can update 85 their list of trust anchors when they've seen a new key published in 86 a zone. However, RFC5011 [intentionally] provides no guidance to the 87 publishers of DNSKEYs about how long they must wait before switching 88 to exclusively using recently published keys for signing records, or 89 how long they must wait before ceasing publication of a revoked key. 90 Because of this lack of guidance, zone publishers may derive 91 incorrect assumptions about safe usage of the RFC5011 DNSKEY 92 advertising, rolling and revocation process. This document describes 93 the minimum security requirements from a publisher's point of view 94 and is intended to complement the guidance offered in RFC5011 (which 95 is written to provide timing guidance solely to a Validating 96 Resolver's point of view). 98 1.1. Document History and Motivation 100 To verify this lack of understanding is wide-spread, the authors 101 reached out to 5 DNSSEC experts to ask them how long they thought 102 they must wait before signing a zone exclusively with a new KSK 103 [RFC4033] that was being introduced according to the 5011 process. 104 All 5 experts answered with an insecure value, and we determined that 105 this lack of operational guidance is causing security concerns today 106 and wrote this companion document to RFC5011. We hope that this 107 document will rectify this understanding and provide better guidance 108 to zone publishers that wish to make use of the RFC5011 rollover 109 process. 111 1.2. Safely Rolling the Root Zone's KSK in 2017/2018 113 One important note about ICANN's [currently upcoming] 2017/2018 KSK 114 rollover plan for the root zone: the timing values chosen for rolling 115 the KSK in the root zone appear completely safe, and are not affected 116 by the timing concerns introduced by this draft 118 1.3. Requirements notation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Background 126 The RFC5011 process describes a process by which a RFC5011 Validating 127 Resolver may accept a newly published KSK as a trust anchor for 128 validating future DNSSEC signed records. It also describes the 129 process for publicly revoking a published KSK. This document 130 augments that information with additional constraints, from the 131 DNSKEY publication and revocation's points of view. Note that this 132 document does not define any other operational guidance or 133 recommendations about the RFC5011 process and restricts itself to 134 solely the security and operational ramifications of switching to 135 exclusively using recently added keys or removing a revoked keys too 136 soon. 138 Failure of a DNSKEY publisher to follow the minimum recommendations 139 associated with this draft will result in potential denial-of-service 140 attack opportunities against validating resolvers. Failure of a 141 DNSKEY publisher to publish a revoked key for a long enough period of 142 time may result in RFC5011 Validating Resolvers leaving that key in 143 their trust anchor storage beyond the key's expected lifetime. 145 3. Terminology 147 Trust Anchor Publisher The entity responsible for publishing a 148 DNSKEY that can be used as a trust anchor. 150 Zone Signer The owner of a zone intending to publish a new Key- 151 Signing-Key (KSK) that will become a trust anchor by validators 152 following the RFC5011 process. 154 RFC5011 Validating Resolver A DNSSEC Validating Resolver that is 155 using the RFC5011 processes to track and update trust anchors. 156 Sometimes referred to as a "RFC5011 Resolver" 158 Attacker An entity intent on foiling the RFC5011 Validator's ability 159 to successfully adopt the Zone Signer's new DNSKEY as a new trust 160 anchor or to prevent the RFC5011 Validator from removing an old 161 DNSKEY from its list of trust anchors. 163 SigExpirationTime The amount of time remaining before a RRSIG's 164 Signature Expiration time is reached. This will fundamentally be 165 the RRSIG's Signature Expiration time minus the RRSIG's Signature 166 Inception time when the signature is created. 168 Also see Section 2 of [RFC4033] and [RFC7719] for additional 169 terminology. 171 4. Timing Associated with RFC5011 Processing 173 These sections define a high-level overview of [RFC5011] processing. 174 These steps are not sufficient for proper RFC5011 implementation, but 175 provide enough background for the reader to follow the discussion in 176 this document. Readers need to fully understand [RFC5011] as well to 177 fully comprehend the importance of this document. 179 4.1. Timing Associated with Publication 181 RFC5011's process of safely publishing a new key and then making use 182 of that key falls into a number of high-level steps to be performed 183 by the Trust Anchor Publisher. This document discusses the following 184 scenario, which is one of many possible combinations of operations 185 defined in Section 6 of RFC5011: 187 1. Publish a new DNSKEY in the zone, but continue to sign the zone 188 with the old one. 190 2. Wait a period of time. 192 3. Begin to exclusively use recently published DNSKEYs to sign the 193 appropriate resource records. 195 This document discusses step 2 of the above process. Some 196 interpretations of RFC5011 have erroneously determined that the wait 197 time is equal to RFC5011's "hold down time". Section 5 describes an 198 attack based on this (common) erroneous belief, which can result in a 199 denial of service attack against the zone. 201 4.2. Timing Associated with Revocation 203 RFC5011's process of advertising that an old key is to be revoked 204 from RFC5011 validating resolvers falls into a number of high-level 205 steps: 207 1. Set the revoke bit on the DNSKEY to be revoked. 209 2. Sign the revoked DNSKEY with itself. 211 3. Wait a period of time. 213 4. Remove the revoked key from the zone. 215 This document discusses step 3 of the above process. Some 216 interpretations of RFC5011 have erroneously determined that the wait 217 time is equal to RFC5011's "hold down time". This document describes 218 an attack based on this (common) erroneous belief, which results in a 219 revoked DNSKEY potentially remaining as a trust anchor in a RFC5011 220 validating resolver long past its expected usage. 222 5. Denial of Service Attack Considerations 224 If an attacker is able to provide a RFC5011 Validating Resolver with 225 past responses, such as when it is in-path or able to perform any 226 number of cache poisoning attacks, the attacker may be able to leave 227 compliant RFC5011-Validating Resolvers without an appropriate DNSKEY 228 trust anchor. This scenario will remain until an administrator 229 manually fixes the situation. 231 The time-line below illustrates this situation. 233 5.1. Enumerated Attack Example 235 The following example settings are used in the example scenario 236 within this section: 238 TTL (all records) 1 day 239 SigExpirationTime 10 days 241 Zone resigned every 1 day 243 Given these settings, the sequence of events in Section 5.1.1 depicts 244 how a Trust Anchor Publisher that waits for only the RFC5011 hold 245 time timer length of 30 days subjects its users to a potential Denial 246 of Service attack. The timing schedule listed below is based on a 247 Trust Anchor Publisher publishing a new Key Signing Key (KSK), with 248 the intent that it will later become a trust anchor. We label this 249 publication time as "T+0". All numbers in this sequence refer to 250 days before and after this initial publication event. Thus, T-1 is 251 the day before the introduction of the new key, and T+15 is the 15th 252 day after the key was introduced into the fictitious zone being 253 discussed. 255 In this dialog, we consider two keys within the example zone: 257 K_old An older KSK and Trust Anchor being replaced. 259 K_new A new KSK being transitioned into active use and expected to 260 become a Trust Anchor via the RFC5011 process. 262 5.1.1. Attack Timing Breakdown 264 The steps shows an attack that foils the adoption of a new DNSKEY by 265 a 5011 Validating Resolver when the Trust Anchor Publisher that 266 starts signing and publishing with the new DNSKEY too quickly. 268 T-1 The K_old based RRSIGs are being published by the Zone Signer. 269 [It may also be signing ZSKs as well, but they are not relevant to 270 this event so we will not talk further about them; we are only 271 considering the RRSIGs that cover the DNSKEYs in this document.] 272 The Attacker queries for, retrieves and caches this DNSKEY set and 273 corresponding RRSIG signatures. 275 T+0 The Zone Signer adds K_new to their zone and signs the zone's 276 key set with K_old. The RFC5011 Validator (later to be under 277 attack) retrieves this new key set and corresponding RRSIGs and 278 notices the publication of K_new. The RFC5011 Validator starts 279 the (30-day) hold-down timer for K_new. [Note that in a more 280 real-world scenario there will likely be a further delay between 281 the point where the Zone Signer publishes a new RRSIG and the 282 RFC5011 Validator notices its publication; though not shown in 283 this example, this delay is accounted for in the final solution 284 below] 286 T+5 The RFC5011 Validator queries for the zone's keyset per the 287 RFC5011 Active Refresh schedule, discussed in Section 2.3 of 288 RFC5011. Instead of receiving the intended published keyset, the 289 Attacker successfully replays the keyset and associated signatures 290 recorded at T-1. Because the signature lifetime is 10 days (in 291 this example), the replayed signature and keyset is accepted as 292 valid (being only 6 days old, which is less than 293 SigExpirationTime) and the RFC5011 Validator cancels the hold-down 294 timer for K_new, per the RFC5011 algorithm. 296 T+10 The RFC5011 Validator queries for the zone's keyset and 297 discovers a signed keyset that includes K_new (again), and is 298 signed by K_old. Note: the attacker is unable to replay the 299 records cached at T-1, because they have now expired. Thus at 300 T+10, the RFC5011 Validator starts (anew) the hold-timer for 301 K_new. 303 T+11 through T-29 The RFC5011 Validator continues checking the 304 zone's key set at the prescribed regular intervals. During this 305 period, the attacker can no longer replay traffic to their 306 benefit. 308 T+30 The Zone Signer knows that this is the first time at which some 309 validators might accept K_new as a new trust anchor, since the 310 hold-down timer of a RFC5011 Validator not under attack that had 311 queried and retrieved K_new at T+0 would now have reached 30 days. 312 However, the hold-down timer of our attacked RFC5011 Validator is 313 only at 20 days. 315 T+35 The Zone Signer (mistakenly) believes that all validators 316 following the Active Refresh schedule (Section 2.3 of RFC5011) 317 should have accepted K_new as a the new trust anchor (since the 318 hold down time (30 days) + the query interval [which is just 1/2 319 the signature validity period in this example] would have passed). 320 However, the hold-down timer of our attacked RFC5011 Validator is 321 only at 25 days (T+35 minus T+10); thus the RFC5011 won't consider 322 it a valid trust anchor addition yet, as the required 30 days have 323 not yet elapsed. 325 T+36 The Zone Signer, believing K_new is safe to use, switches their 326 active signing KSK to K_new and publishes a new RRSIG, signed with 327 K_new, covering the DNSKEY set. Non-attacked RFC5011 validators, 328 with a hold-down timer of at least 30 days, would have accepted 329 K_new into their set of trusted keys. But, because our attacked 330 RFC5011 Validator now has a hold-down timer for K_new of only 26 331 days, it failed to accept K_new as a trust anchor. Since K_old is 332 no longer being used to sign the zone's DNSKEYs, all the DNSKEY 333 records from the zone will be treated as invalid. Subsequently, 334 all of the records in the DNS tree below the zone's apex will be 335 deemed invalid by DNSSEC. 337 6. Minimum RFC5011 Timing Requirements 339 6.1. Timing Requirements For Adding a New KSK 341 Given the attack description in Section 5, the correct minimum length 342 of time required for the Zone Signer to wait after publishing K_new 343 but before exclusively using it and newer keys is: 345 addWaitTime = addHoldDownTime 346 + SigExpirationTime 347 + activeRefresh 348 + activeRefreshOffset 349 + 2 * MAX(TTL of all records) 351 Where activeRefresh time is defined by RFC5011 by: 353 A resolver that has been configured for an automatic update 354 of keys from a particular trust point MUST query that trust 355 point (e.g., do a lookup for the DNSKEY RRSet and related 356 RRSIG records) no less often than the lesser of 15 days, half 357 the original TTL for the DNSKEY RRSet, or half the RRSIG 358 expiration interval and no more often than once per hour. 360 This translates to the following equation: 362 activeRefresh = MAX(1 hour, 363 MIN(SigExpirationTime / 2, 364 MAX(TTL of K_old DNSKEY RRSet) / 2, 365 15 days) 366 ) 368 The activeRefreshOffset term must be added for situations where the 369 activeRefresh value is not a factor of "30 days". Specifically, 370 activeRefreshOffset will be "(30 days) % activeRefresh", where % is 371 the mathematical mod operator (which calculates the remainder in a 372 division problem). This will frequently be zero, but could be nearly 373 as large as activeRefresh itself. For simplicity, setting the 374 activeRefreshOffset to the activeRefresh value itself is safe. 376 The full expanded equation, with activeRefreshOffset set to 377 activeRefresh for simplicity, is: 379 addWaitTime = addHoldDownTime 380 + SigExpirationTime 381 + 2 * MAX(1 hour, 382 MIN(SigExpirationTime / 2, 383 MAX(TTL of K_old DNSKEY RRSet) / 2, 384 15 days) 385 ) 386 + 2 * MAX(TTL of all records) 388 The important timing constraint introduced by this memo relates to 389 the last point at which a validating resolver may have received a 390 replayed original DNSKEY set, containing K_old and not K_new. The 391 next query of the RFC5011 validator at which K_new will be seen 392 without the potential for a replay attack will occur after the 393 publication time plus SigExpirationTime. Thus, the latest time that 394 a RFC5011 Validator may begin their hold down timer is an "Active 395 Refresh" period after the last point that an attacker can replay the 396 K_old DNSKEY set. The worst case scenario of this attack is if the 397 attacker can replay K_old seconds before the (DNSKEY RRSIG Signature 398 Validity) field of the last K_old only RRSIG. 400 RFC5011 also discusses a retryTime value for failed queries. Our 401 equation cannot take into account undeterministic failure situations, 402 so it might be wise to extend the addWaitTime by some factor of 403 retryTime, which is defined in RFC5011 as: 405 retryTime = MAX (1 hour, 406 MIN (1 day, 407 .1 * TTL of K_old DNSKEY RRset, 408 .1 * SigExpirationTime)) 410 The extra 2 * MAX(TTL of all records) is the standard added safety 411 margin when dealing with DNSSEC due to caching that can take place. 412 Because the 5011 steps require direct validation using the signature 413 validity, the authors aren't yet convinced it is needed in this 414 particular case, but it is prudent to include it for added assurance. 416 Note: our notion of addWaitTime is called "Itrp" in Section 3.3.4.1 417 of [RFC7583]. The equation for Itrp in RFC7583 is insecure as it 418 does not include the SigExpirationTime listed above. The Itrp 419 equation in RFC7583 also does not include the 2*TTL safety margin, 420 though that is an operational consideration and not necessarily as 421 critical. 423 6.1.1. Example Results 425 For the parameters listed in Section 5.1, the activeRefreshOffset is 426 0, since 30 days is evenly divisible by activeRefresh (1/2 day), and 427 our resulting addWaitTime is: 429 addWaitTime = 30 430 + 10 431 + 1 / 2 432 + 2 * (1) (days) 434 addWaitTime = 42.5 (days) 436 This addWaitTime of 42.5 days is 12.5 days longer than just the hold 437 down timer. 439 6.2. Timing Requirements For Revoking an Old KSK 441 It is important to note that this issue affects not just the 442 publication of new DNSKEYs intended to be used as trust anchors, but 443 also the length of time required to continuously publish a DNSKEY 444 with the revoke bit set. Both of these publication timing 445 requirements are affected by the attacks described in this document, 446 but with revocation the key is revoked immediately and the 447 addHoldDown timer does not apply. Thus the minimum amount of time 448 that a Trust Anchor Publisher must wait before removing a revoked key 449 from publication is: 451 remWaitTime = SigExpirationTime 452 + MAX(1 hour, 453 MIN((SigExpirationTime) / 2, 454 MAX(TTL of K_old DNSKEY RRSet) / 2, 455 15 days), 456 1 hour) 457 + 2 * MAX(TTL of all records) 459 Note that the activeRefreshOffset time does not apply to this 460 equation. 462 Note that our notion of remWaitTime is called "Irev" in 463 Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is 464 insecure as it does not include the SigExpirationTime listed above. 465 The Irev equation in RFC7583 also does not include the 2*TTL safety 466 margin, though that is an operational consideration and not 467 necessarily as critical. 469 Note also that adding retryTime intervals to the remWaitTime may be 470 wise, just as it was for addWaitTime in Section 6. 472 6.2.1. Example Results 474 For the parameters listed in Section 5.1, our example: 476 remwaitTime = 10 477 + 1 / 2 478 + 2 * (1) (days) 480 remwaitTime = 12.5 (days) 482 Note that for the values in this example produce a length shorter 483 than the recommended 30 days in RFC5011's section 6.6, step 3. Other 484 values of SigExpirationTime and the original TTL of the K_old DNSKEY 485 RRSet, however, can produce values longer than 30 days. 487 Note that because revocation happens immediately, an attacker has a 488 much harder job tricking a RFC5011 Validator into leaving a trust 489 anchor in place, as the attacker must successfully replay the old 490 data for every query a RFC5011 Validator sends, not just one. 492 7. IANA Considerations 494 This document contains no IANA considerations. 496 8. Operational Considerations 498 A companion document to RFC5011 was expected to be published that 499 describes the best operational practice considerations from the 500 perspective of a zone publisher and Trust Anchor Publisher. However, 501 this companion document has yet to be published. The authors of this 502 document hope that it will at some point in the future, as RFC5011 503 timing can be tricky as we have shown, and a BCP is clearly 504 warranted. This document is intended only to fill a single 505 operational void which, when left misunderstood, can result in 506 serious security ramifications. This document does not attempt to 507 document any other missing operational guidance for zone publishers. 509 9. Security Considerations 511 This document, is solely about the security considerations with 512 respect to the Trust Anchor Publisher of RFC5011 trust anchors / 513 DNSKEYs. Thus the entire document is a discussion of Security 514 Considerations when adding or removing DNSKEYs from trust anchor 515 storage using the RFC5011 process. 517 For simplicity, this document assumes that the Trust Anchor Publisher 518 will use a consistent RRSIG validity period. Trust Anchor Publishers 519 that vary the length of RRSIG validity periods will need to adjust 520 the SigExpirationTime value accordingly so that the equations in 521 Section 6 and Section 6.2 use a value that coincides with the last 522 time a replay of older RRSIGs will no longer succeed. 524 10. Acknowledgements 526 The authors would like to especially thank to Michael StJohns for his 527 help and advice and the care and thought he put into RFC5011 itself. 528 We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking, 529 Duane Wessels, Petr Petr Spacek, and the dnsop working group who have 530 assisted with this document. 532 11. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, . 539 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 540 Rose, "DNS Security Introduction and Requirements", 541 RFC 4033, DOI 10.17487/RFC4033, March 2005, 542 . 544 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 545 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 546 September 2007, . 548 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 549 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 550 DOI 10.17487/RFC7583, October 2015, . 553 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 554 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 555 2015, . 557 Appendix A. Real World Example: The 2017 Root KSK Key Roll 559 In 2017, ICANN expects to (or has, depending on when you're reading 560 this) roll the key signing key (KSK) for the root zone. The relevant 561 parameters associated with the root zone at the time of this writing 562 is as follows: 564 addHoldDownTime: 30 days 565 Old DNSKEY SigExpirationTime: 21 days 566 Old DNSKEY TTL: 2 days 568 Thus, sticking this information into the equation in 569 Section Section 6 yields (in days): 571 addWaitTime = 30 572 + (21) 573 + MAX(MIN((21) / 2, 574 MAX(2 / 2, 575 15 days)), 576 1 hour) 577 + 2 * MAX(2) 579 addWaitTime = 30 + 21 + MAX(MIN(11.5, 1, 15)), 1 hour) + 4 581 addWaitTime = 30 + 21 + 1 + 4 583 addWaitTime = 56 days 585 Note that we use a activeRefreshOffset of 0, since 30 days is evenly 586 divisible by activeRefresh (1 day). 588 Thus, ICANN should wait a minimum of 56 days before switching to the 589 newly published KSK (and 26 days before removing the old revoked key 590 once it is published as revoked). ICANN's current plans are to wait 591 70 days before using the new KEY and 69 days before removing the old, 592 revoked key. Thus, their current rollover plans are sufficiently 593 secure from the attack discussed in this memo. 595 Authors' Addresses 597 Wes Hardaker 598 USC/ISI 599 P.O. Box 382 600 Davis, CA 95617 601 US 603 Email: ietf@hardakers.net 605 Warren Kumari 606 Google 607 1600 Amphitheatre Parkway 608 Mountain View, CA 94043 609 US 611 Email: warren@kumari.net