idnits 2.17.1 draft-ietf-dnsop-rfc5011-security-considerations-07.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 (October 18, 2017) is 2354 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: April 21, 2018 October 18, 2017 8 Security Considerations for RFC5011 Publishers 9 draft-ietf-dnsop-rfc5011-security-considerations-07 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 April 21, 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 . . . . . . . . . . 5 70 4.1. Timing Associated with Publication . . . . . . . . . . . 5 71 4.2. Timing Associated with Revocation . . . . . . . . . . . . 5 72 5. Denial of Service Attack Considerations . . . . . . . . . . . 6 73 5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6 74 5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 9 79 6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 9 80 6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9 81 6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 9 82 6.1.6. Fully expanded equation . . . . . . . . . . . . . . . 10 83 6.1.7. Timing Constraint Summary . . . . . . . . . . . . . . 10 84 6.1.8. Additional Considerations . . . . . . . . . . . . . . 11 85 6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 11 86 6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 8. Operational Considerations . . . . . . . . . . . . . . . . . 12 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 91 11. Normative References . . . . . . . . . . . . . . . . . . . . 13 92 Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 14 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 the latest 177 RRSIG's Signature Expiration time is reached. Note that for 178 organizations pre-creating signatures this time may be fairly 179 lengthy unless they can be significantly assured their signatures 180 can not be replayed at a later date. sigExpirationTime will 181 fundamentally be the RRSIG's Signature Expiration time minus the 182 RRSIG's Signature Inception time when the signature is created. 184 Also see Section 2 of [RFC4033] and [RFC7719] for additional 185 terminology. 187 4. Timing Associated with RFC5011 Processing 189 These sections define a high-level overview of [RFC5011] processing. 190 These steps are not sufficient for proper RFC5011 implementation, but 191 provide enough background for the reader to follow the discussion in 192 this document. Readers need to fully understand [RFC5011] as well to 193 fully comprehend the importance of this document. 195 4.1. Timing Associated with Publication 197 RFC5011's process of safely publishing a new key and then making use 198 of that key falls into a number of high-level steps to be performed 199 by the Trust Anchor Publisher. This document discusses the following 200 scenario, which the principle way RFC5011 is currently being used 201 (even though Section 6 of RFC5011 suggests having a stand-by key 202 available): 204 1. Publish a new DNSKEY in the zone, but continue to sign the zone 205 with the old one. 207 2. Wait a period of time. 209 3. Begin to exclusively use recently published DNSKEYs to sign the 210 appropriate resource records. 212 This document discusses step 2 of the above process. Some 213 interpretations of RFC5011 have erroneously determined that the wait 214 time is equal to RFC5011's "hold down time". Section 5 describes an 215 attack based on this (common) erroneous belief, which can result in a 216 denial of service attack against the zone. 218 4.2. Timing Associated with Revocation 220 RFC5011's process of advertising that an old key is to be revoked 221 from RFC5011 validating resolvers falls into a number of high-level 222 steps: 224 1. Set the revoke bit on the DNSKEY to be revoked. 226 2. Sign the revoked DNSKEY with itself. 228 3. Wait a period of time. 230 4. Remove the revoked key from the zone. 232 This document discusses step 3 of the above process. Some 233 interpretations of RFC5011 have erroneously determined that the wait 234 time is equal to RFC5011's "hold down time". This document describes 235 an attack based on this (common) erroneous belief, which results in a 236 revoked DNSKEY potentially remaining as a trust anchor in a RFC5011 237 validating resolver long past its expected usage. 239 5. Denial of Service Attack Considerations 241 If an attacker is able to provide a RFC5011 Validating Resolver with 242 past responses, such as when it is in-path or able to perform any 243 number of cache poisoning attacks, the attacker may be able to leave 244 compliant RFC5011-Validating Resolvers without an appropriate DNSKEY 245 trust anchor. This scenario will remain until an administrator 246 manually fixes the situation. 248 The time-line below illustrates this situation. 250 5.1. Enumerated Attack Example 252 The following example settings are used in the example scenario 253 within this section: 255 TTL (all records) 1 day 257 sigExpirationTime 10 days 259 Zone resigned every 1 day 261 Given these settings, the sequence of events in Section 5.1.1 depicts 262 how a Trust Anchor Publisher that waits for only the RFC5011 hold 263 time timer length of 30 days subjects its users to a potential Denial 264 of Service attack. The timing schedule listed below is based on a 265 Trust Anchor Publisher publishing a new Key Signing Key (KSK), with 266 the intent that it will later become a trust anchor. We label this 267 publication time as "T+0". All numbers in this sequence refer to 268 days before and after this initial publication event. Thus, T-1 is 269 the day before the introduction of the new key, and T+15 is the 15th 270 day after the key was introduced into the fictitious zone being 271 discussed. 273 In this dialog, we consider two keys within the example zone: 275 K_old An older KSK and Trust Anchor being replaced. 277 K_new A new KSK being transitioned into active use and expected to 278 become a Trust Anchor via the RFC5011 process. 280 5.1.1. Attack Timing Breakdown 282 The steps shows an attack that foils the adoption of a new DNSKEY by 283 a 5011 Validating Resolver when the Trust Anchor Publisher that 284 starts signing and publishing with the new DNSKEY too quickly. 286 T-1 The K_old based RRSIGs are being published by the Zone Signer. 287 [It may also be signing ZSKs as well, but they are not relevant to 288 this event so we will not talk further about them; we are only 289 considering the RRSIGs that cover the DNSKEYs in this document.] 290 The Attacker queries for, retrieves and caches this DNSKEY set and 291 corresponding RRSIG signatures. Note that for simplicity we 292 assume the signer is not pre-signing and creating "valid in the 293 future" signature sets that may be stolen and replayed even later. 295 T+0 The Zone Signer adds K_new to their zone and signs the zone's 296 key set with K_old. The RFC5011 Validator (later to be under 297 attack) retrieves this new key set and corresponding RRSIGs and 298 notices the publication of K_new. The RFC5011 Validator starts 299 the (30-day) hold-down timer for K_new. [Note that in a more 300 real-world scenario there will likely be a further delay between 301 the point where the Zone Signer publishes a new RRSIG and the 302 RFC5011 Validator notices its publication; though not shown in 303 this example, this delay is accounted for in the final solution 304 below] 306 T+5 The RFC5011 Validator queries for the zone's keyset per the 307 RFC5011 Active Refresh schedule, discussed in Section 2.3 of 308 RFC5011. Instead of receiving the intended published keyset, the 309 Attacker successfully replays the keyset and associated signatures 310 recorded at T-1. Because the signature lifetime is 10 days (in 311 this example), the replayed signature and keyset is accepted as 312 valid (being only 6 days old, which is less than 313 sigExpirationTime) and the RFC5011 Validator cancels the hold-down 314 timer for K_new, per the RFC5011 algorithm. 316 T+10 The RFC5011 Validator queries for the zone's keyset and 317 discovers a signed keyset that includes K_new (again), and is 318 signed by K_old. Note: the attacker is unable to replay the 319 records cached at T-1, because they have now expired. Thus at 320 T+10, the RFC5011 Validator starts (anew) the hold-timer for 321 K_new. 323 T+11 through T+29 The RFC5011 Validator continues checking the 324 zone's key set at the prescribed regular intervals. During this 325 period, the attacker can no longer replay traffic to their 326 benefit. 328 T+30 The Zone Signer knows that this is the first time at which some 329 validators might accept K_new as a new trust anchor, since the 330 hold-down timer of a RFC5011 Validator not under attack that had 331 queried and retrieved K_new at T+0 would now have reached 30 days. 332 However, the hold-down timer of our attacked RFC5011 Validator is 333 only at 20 days. 335 T+35 The Zone Signer (mistakenly) believes that all validators 336 following the Active Refresh schedule (Section 2.3 of RFC5011) 337 should have accepted K_new as a the new trust anchor (since the 338 hold down time (30 days) + the query interval [which is just 1/2 339 the signature validity period in this example] would have passed). 340 However, the hold-down timer of our attacked RFC5011 Validator is 341 only at 25 days (T+35 minus T+10); thus the RFC5011 won't consider 342 it a valid trust anchor addition yet, as the required 30 days have 343 not yet elapsed. 345 T+36 The Zone Signer, believing K_new is safe to use, switches their 346 active signing KSK to K_new and publishes a new RRSIG, signed with 347 K_new, covering the DNSKEY set. Non-attacked RFC5011 validators, 348 with a hold-down timer of at least 30 days, would have accepted 349 K_new into their set of trusted keys. But, because our attacked 350 RFC5011 Validator now has a hold-down timer for K_new of only 26 351 days, it failed to accept K_new as a trust anchor. Since K_old is 352 no longer being used to sign the zone's DNSKEYs, all the DNSKEY 353 records from the zone will be treated as invalid. Subsequently, 354 all of the records in the DNS tree below the zone's apex will be 355 deemed invalid by DNSSEC. 357 6. Minimum RFC5011 Timing Requirements 359 6.1. Timing Requirements For Adding a New KSK 361 Given the attack description in Section 5, the correct minimum length 362 of time required for the Zone Signer to wait after publishing K_new 363 but before exclusively using it and newer keys is: 365 addWaitTime = addHoldDownTime 366 + sigExpirationTime 367 + activeRefresh 368 + activeRefreshOffset 369 + safetyMargin 371 6.1.1. addHoldDownTime 373 The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as: 375 The add hold-down time is 30 days or the expiration time of the 376 original TTL of the first trust point DNSKEY RRSet that contained 377 the new key, whichever is greater. This ensures that at least 378 two validated DNSKEY RRSets that contain the new key MUST be seen 379 by the resolver prior to the key's acceptance. 381 6.1.2. sigExpirationTime 383 sigExpirationTime is defined in Section 3. 385 6.1.3. activeRefresh 387 activeRefresh time is defined by RFC5011 by 389 A resolver that has been configured for an automatic update 390 of keys from a particular trust point MUST query that trust 391 point (e.g., do a lookup for the DNSKEY RRSet and related 392 RRSIG records) no less often than the lesser of 15 days, half 393 the original TTL for the DNSKEY RRSet, or half the RRSIG 394 expiration interval and no more often than once per hour. 396 This translates to: 398 activeRefresh = MAX(1 hour, 399 MIN(sigExpirationTime / 2, 400 MAX(TTL of K_old DNSKEY RRSet) / 2, 401 15 days) 402 ) 404 6.1.4. activeRefreshOffset 406 The activeRefreshOffset term must be added for situations where the 407 activeRefresh value is not a factor of the addHoldDownTime. 408 Specifically, activeRefreshOffset will be "addHoldDownTime % 409 activeRefresh", where % is the mathematical mod operator (calculating 410 the remainder in a division problem). This will frequently be zero, 411 but could be nearly as large as activeRefresh itself. For 412 simplicity, setting the activeRefreshOffset to the activeRefresh 413 value itself is always safe. 415 6.1.5. safetyMargin 417 The safetyMargin is an extra period of time to account for caching, 418 network delays, etc. A suggested operational value for this is 2 * 419 MAX(TTL of all records) unless the TTLs are shorter than an hour, at 420 which point they start affecting the calculations in the MIN() clause 421 in the activeRefresh timer in Section 6.1.3. Thus, we suggest a 422 safetyMargin of at least: 424 safetyMargin = MAX (1.5 hours, 2 * MAX(TTL of all records)) 426 RFC5011 also discusses a retryTime value for failed queries. Our 427 equation cannot take into account undeterministic failure situations, 428 so it might be wise to extend the safetyMargin by some factor of 429 retryTime, which is defined in RFC5011 as: 431 retryTime = MAX (1 hour, 432 MIN (1 day, 433 .1 * TTL of K_old DNSKEY RRset, 434 .1 * sigExpirationTime)) 436 6.1.6. Fully expanded equation 438 The full expanded equation, with activeRefreshOffset set to 439 activeRefresh for simplicity, is: 441 addWaitTime = addHoldDownTime 442 + sigExpirationTime 443 + 2 * MAX(1 hour, 444 MIN(sigExpirationTime / 2, 445 MAX(TTL of K_old DNSKEY RRSet) / 2, 446 15 days) 447 ) 448 + (addHoldDownTime % activeRefresh) 449 + MAX(1.5 hours, 2 * MAX(TTL of all records)) 451 6.1.7. Timing Constraint Summary 453 The important timing constraint introduced by this memo relates to 454 the last point at which a validating resolver may have received a 455 replayed original DNSKEY set, containing K_old and not K_new. The 456 next query of the RFC5011 validator at which K_new will be seen 457 without the potential for a replay attack will occur after the 458 publication time plus sigExpirationTime. Thus, the latest time that 459 a RFC5011 Validator may begin their hold down timer is an "Active 460 Refresh" period after the last point that an attacker can replay the 461 K_old DNSKEY set. The worst case scenario of this attack is if the 462 attacker can replay K_old seconds before the (DNSKEY RRSIG Signature 463 Validity) field of the last K_old only RRSIG. 465 6.1.8. Additional Considerations 467 Note: our notion of addWaitTime is called "Itrp" in Section 3.3.4.1 468 of [RFC7583]. The equation for Itrp in RFC7583 is insecure as it 469 does not include the sigExpirationTime listed above. The Itrp 470 equation in RFC7583 also does not include the 2*TTL safety margin, 471 though that is an operational consideration and not necessarily as 472 critical. 474 6.1.8.1. Example Results 476 For the parameters listed in Section 5.1, the activeRefreshOffset is 477 0, since 30 days is evenly divisible by activeRefresh (1/2 day), and 478 our resulting addWaitTime is: 480 addWaitTime = 30 481 + 10 482 + 1 / 2 483 + 2 * (1) (days) 485 addWaitTime = 42.5 (days) 487 This addWaitTime of 42.5 days is 12.5 days longer than just the hold 488 down timer. 490 6.2. Timing Requirements For Revoking an Old KSK 492 It is important to note that this issue affects not just the 493 publication of new DNSKEYs intended to be used as trust anchors, but 494 also the length of time required to continuously publish a DNSKEY 495 with the revoke bit set. Both of these publication timing 496 requirements are affected by the attacks described in this document, 497 but with revocation the key is revoked immediately and the 498 addHoldDown timer does not apply. Thus the minimum amount of time 499 that a Trust Anchor Publisher must wait before removing a revoked key 500 from publication is: 502 remWaitTime = sigExpirationTime 503 + MAX(1 hour, 504 MIN((sigExpirationTime) / 2, 505 MAX(TTL of K_old DNSKEY RRSet) / 2, 506 15 days), 507 1 hour) 508 + 2 * MAX(TTL of all records) 510 Note that the activeRefreshOffset time does not apply to this 511 equation. 513 Note that our notion of remWaitTime is called "Irev" in 514 Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is 515 insecure as it does not include the sigExpirationTime listed above. 516 The Irev equation in RFC7583 also does not include the 2*TTL safety 517 margin, though that is an operational consideration and not 518 necessarily as critical. 520 Note also that adding retryTime intervals to the remWaitTime may be 521 wise, just as it was for addWaitTime in Section 6. 523 6.2.1. Example Results 525 For the parameters listed in Section 5.1, our example: 527 remwaitTime = 10 528 + 1 / 2 529 + 2 * (1) (days) 531 remwaitTime = 12.5 (days) 533 Note that for the values in this example produce a length shorter 534 than the recommended 30 days in RFC5011's section 6.6, step 3. Other 535 values of sigExpirationTime and the original TTL of the K_old DNSKEY 536 RRSet, however, can produce values longer than 30 days. 538 Note that because revocation happens immediately, an attacker has a 539 much harder job tricking a RFC5011 Validator into leaving a trust 540 anchor in place, as the attacker must successfully replay the old 541 data for every query a RFC5011 Validator sends, not just one. 543 7. IANA Considerations 545 This document contains no IANA considerations. 547 8. Operational Considerations 549 A companion document to RFC5011 was expected to be published that 550 describes the best operational practice considerations from the 551 perspective of a zone publisher and Trust Anchor Publisher. However, 552 this companion document has yet to be published. The authors of this 553 document hope that it will at some point in the future, as RFC5011 554 timing can be tricky as we have shown, and a BCP is clearly 555 warranted. This document is intended only to fill a single 556 operational void which, when left misunderstood, can result in 557 serious security ramifications. This document does not attempt to 558 document any other missing operational guidance for zone publishers. 560 9. Security Considerations 562 This document, is solely about the security considerations with 563 respect to the Trust Anchor Publisher of RFC5011 trust anchors / 564 DNSKEYs. Thus the entire document is a discussion of Security 565 Considerations when adding or removing DNSKEYs from trust anchor 566 storage using the RFC5011 process. 568 For simplicity, this document assumes that the Trust Anchor Publisher 569 will use a consistent RRSIG validity period. Trust Anchor Publishers 570 that vary the length of RRSIG validity periods will need to adjust 571 the sigExpirationTime value accordingly so that the equations in 572 Section 6 and Section 6.2 use a value that coincides with the last 573 time a replay of older RRSIGs will no longer succeed. 575 10. Acknowledgements 577 The authors would like to especially thank to Michael StJohns for his 578 help and advice and the care and thought he put into RFC5011 itself. 579 We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking, 580 Duane Wessels, Petr Petr Spacek, Ed Lewis, and the dnsop working 581 group who have assisted with this document. 583 11. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 589 Rose, "DNS Security Introduction and Requirements", 590 RFC 4033, DOI 10.17487/RFC4033, March 2005, 591 . 593 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 594 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 595 September 2007, . 597 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 598 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 599 DOI 10.17487/RFC7583, October 2015, . 602 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 603 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 604 2015, . 606 Appendix A. Real World Example: The 2017 Root KSK Key Roll 608 In 2017, ICANN expects to (or has, depending on when you're reading 609 this) roll the key signing key (KSK) for the root zone. The relevant 610 parameters associated with the root zone at the time of this writing 611 is as follows: 613 addHoldDownTime: 30 days 614 Old DNSKEY sigExpirationTime: 21 days 615 Old DNSKEY TTL: 2 days 617 Thus, sticking this information into the equation in 618 Section Section 6 yields (in days): 620 addWaitTime = 30 621 + (21) 622 + MAX(MIN((21) / 2, 623 MAX(2 / 2, 624 15 days)), 625 1 hour) 626 + 2 * MAX(2) 628 addWaitTime = 30 + 21 + MAX(MIN(11.5, 1, 15)), 1 hour) + 4 630 addWaitTime = 30 + 21 + 1 + 4 632 addWaitTime = 56 days 634 Note that we use a activeRefreshOffset of 0, since 30 days is evenly 635 divisible by activeRefresh (1 day). 637 Thus, ICANN should wait a minimum of 56 days before switching to the 638 newly published KSK (and 26 days before removing the old revoked key 639 once it is published as revoked). ICANN's current plans are to wait 640 70 days before using the new KEY and 69 days before removing the old, 641 revoked key. Thus, their current rollover plans are sufficiently 642 secure from the attack discussed in this memo. 644 Authors' Addresses 646 Wes Hardaker 647 USC/ISI 648 P.O. Box 382 649 Davis, CA 95617 650 US 652 Email: ietf@hardakers.net 653 Warren Kumari 654 Google 655 1600 Amphitheatre Parkway 656 Mountain View, CA 94043 657 US 659 Email: warren@kumari.net