idnits 2.17.1 draft-ietf-dnsop-rfc5011-security-considerations-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2017) is 2488 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) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop W. Hardaker 3 Internet-Draft USC/ISI 4 Intended status: Standards Track W. Kumari 5 Expires: December 29, 2017 Google 6 June 27, 2017 8 Security Considerations for RFC5011 Publishers 9 draft-ietf-dnsop-rfc5011-security-considerations-02 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 with 17 only recently added DNSKEYs. This document also describes the 18 minimum time-length that a DNS zone publisher must wait after 19 publishing a revoked DNSKEY before assuming that all active RFC5011 20 resolvers should have seen the revocation-marked key and removed it 21 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 December 29, 2017. 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 . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. Operational Considerations . . . . . . . . . . . . . . . . . 9 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 10 76 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 [RFC5011] defines a mechanism by which DNSSEC validators can extend 82 their list of trust anchors when they've seen a new key published in 83 a zone. However, RFC5011 [intentionally] provides no guidance to the 84 publishers of DNSKEYs about how long they must wait before switching 85 to using only recently published keys for signing records, or how 86 long they must wait before removing a revoked key from a zone. 87 Because of this lack of guidance, zone publishers may derive 88 incorrect assumptions about safe usage of the RFC5011 DNSKEY 89 advertising, rolling and revocation process. This document describes 90 the minimum security requirements from a publisher's point of view 91 and is intended to compliment the guidance offered in RFC5011 (which 92 is written to provide timing guidance solely to a Validating 93 Resolver's point of view). 95 1.1. Document History and Motivation 97 To verify this lack of understanding is wide-spread, the authors 98 reached out to 5 DNSSEC experts to ask them how long they thought 99 they must wait before signing a zone using a new KSK [RFC4033] that 100 was being rolled according to the 5011 process. All 5 experts 101 answered with an insecure value, and we determined that this lack of 102 operational guidance is causing security concerns today and wrote 103 this companion document to RFC5011. We hope that this document will 104 rectify this understanding and provide better guidance to zone 105 publishers that wish to make use of the RFC5011 rollover process. 107 1.2. Safely Rolling the Root Zone's KSK in 2017/2018 109 One important note about ICANN's [currently upcoming] 2017/2018 KSK 110 rollover plan for the root zone: the timing values chosen for rolling 111 the KSK in the root zone appear completely safe, and are not affected 112 by the timing concerns introduced by this draft 114 1.3. Requirements notation 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2. Background 122 The RFC5011 process describes a process by which a RFC5011 Validating 123 Resolver may accept a newly published KSK as a trust anchor for 124 validating future DNSSEC signed records. It also describes the 125 process for publicly revoking a published KSK. This document 126 augments that information with additional constraints, as required 127 from the DNSKEY publication and revocation's points of view. Note 128 that it does not define any other operational guidance or 129 recommendations about the RFC5011 process and restricts itself to 130 solely the security and operational ramifications of switching to 131 using only recently added keys or removing a revoked keys too soon. 132 Failure of a DNSKEY publisher to follow the minimum recommendations 133 associated with this draft will result in potential denial-of-service 134 attack opportunities against validating resolvers. Failure of a 135 DNSKEY publisher to publish a revoked key for a long enough period of 136 time may result in RFC5011 Validating Resolvers leaving a key in 137 their trust anchor storage beyond their expected lifetime. 139 3. Terminology 141 Trust Anchor Publisher The entity responsible for publishing a 142 DNSKEY that can be used as a trust anchor. 144 Zone Signer The owner of a zone intending to publish a new Key- 145 Signing-Key (KSK) that will become a trust anchor by validators 146 following the RFC5011 process. 148 RFC5011 Validating Resolver A DNSSEC Validating Resolver that is 149 using the RFC5011 processes to track and update trust anchors. 150 Sometimes referred to as a "RFC5011 Resolver" 152 Attacker An attacker intent on foiling the RFC5011 Validator's 153 ability to successfully adopt the Zone Signer's new DNSKEY as a 154 new trust anchor or to prevent the RFC5011 Validator from removing 155 an old DNSKEY from its list of trust anchors. 157 Also see Section 2 of [RFC4033] and [RFC7719] for additional 158 terminology. 160 4. Timing Associated with RFC5011 Processing 162 4.1. Timing Associated with Publication 164 RFC5011's process of safely publishing a new key and then making use 165 of that key falls into a number of high-level steps to be performed 166 by the Trust Anchor Publisher: 168 1. Publish a new DNSKEY in the zone, but continue to sign the zone 169 with the old one. 171 2. Wait a period of time. 173 3. Begin using only recently published DNSKEYs to sign the 174 appropriate resource records. 176 This document discusses step 2 of the above process. Some 177 interpretations of RFC5011 have erroneously determined that the wait 178 time is equal to RFC5011's "hold down time". 180 Section 5 describes an attack based on this (common) erroneous 181 belief, which results in a denial of service attack against the zone 182 if that value is used. 184 4.2. Timing Associated with Revocation 186 RFC5011's process of advertising that an old key is to be revoked 187 from RFC5011 validating resolvers falls into a number of high-level 188 steps: 190 1. Set the revoke bit on the DNSKEY to be revoked. 192 2. Sign the revoked DNSKEY with itself. 194 3. Wait a period of time. 196 4. Remove the revoked key from the zone. 198 This document discusses step 3 of the above process. Some 199 interpretations of RFC5011 have erroneously determined that the wait 200 time is equal to RFC5011's "hold down time". 202 This document describes an attack based on this (common) erroneous 203 belief, which results in a revoked DNSKEY potentially staying in a 204 RFC5011 validating resolver long past its expected usage. 206 5. Denial of Service Attack Considerations 208 If an attacker is able to provide a RFC5011 Validating Resolver with 209 past responses, such as when it is in-path or able to otherwise 210 perform any number of cache poisoning attacks, the attacker may be 211 able to leave compliant RFC5011-Validating Resolvers without an 212 appropriate DNSKEY trust anchor. This scenario will remain until an 213 administrator manually fixes the situation. 215 The following timeline illustrates this situation. 217 5.1. Enumerated Attack Example 219 The following example settings are used in the example scenario 220 within this section: 222 TTL (all records) 1 day 224 DNSKEY RRSIG Signature Validity 10 days 226 Zone resigned every 1 day 228 Given these settings, the sequence of events in Section 5.1.1 depicts 229 how a Trust Anchor Publisher that waits for only the RFC5011 hold 230 time timer length of 30 days subjects its users to a potential Denial 231 of Service attack. The timing schedule listed below is based on a 232 Trust Anchor Publisher publishing a new Key Signing Key (KSK), with 233 the intent that it will later become a trust anchor. We label this 234 publication time as "T+0". All numbers in this sequence refer to 235 days before and after this initial publication event. Thus, T-1 is 236 the day before the introduction of the new key, and T+15 is the 15th 237 day after the key was introduced into the fictitious zone being 238 discussed. 240 In this dialog, we consider two keys being published: 242 K_old An older KSK and Trust Anchor being replaced. 244 K_new A new KSK being transitioned into active use and becoming a 245 Trust Anchor via the RFC5011 process. 247 5.1.1. Attack Timing Breakdown 249 The following series of steps depicts the timeline in which an attack 250 occurs that foils the adoption of a new DNSKEY by a Trust Anchor 251 Publisher that starts signing with the new DNSKEY too quickly. 253 T-1 The last RRSIGs are published by the Zone Signer that signs only 254 K_old key using the K_old key itself. [It may also be signing 255 ZSKs as well, but they are not relevant to this event so we will 256 not talk further about them; we are only talking about RRSIGs that 257 cover the DNSKEYs.] The Attacker queries for, retrieves and 258 caches this DNSKEY set and corresponding RRSIG signatures. 260 T-0 The Zone Signer adds K_new to their zone and signs the zone's 261 key set with K_old. The RFC5011 Validator (later to be under 262 attack) retrieves this new key set and corresponding RRSIGs and 263 notices the publication of K_new. The RFC5011 Validator starts 264 the (30-day) hold-down timer for K_new. 266 T+5 The RFC5011 Validator queries for the zone's keyset per the 267 RFC5011 Active Refresh schedule, discussed in Section 2.3 of 268 RFC5011. Instead of receiving the intended published keyset, the 269 Attacker successfully replays the keyset and associated signatures 270 that they recorded at T-1. Because the signature lifetime is 10 271 days (in this example), the replayed signature and keyset is 272 accepted as valid (being only 6 days old) and the RFC5011 273 Validator cancels the hold-down timer for K_new, per the RFC5011 274 algorithm. 276 T+10 The RFC5011 Validator queries for the zone's keyset and 277 discovers the new kset which includes K_new (again), signed by 278 K_old. Note: the attacker is unable to replay the records cached 279 at T-1, because they have now expired. The RFC5011 Validator 280 starts (anew) the hold-timer for K_new. 282 T+15,T+20, and T+25 The RFC5011 Validator continues checking the 283 zone's key set at the prescribed regular intervals. The RFC5011 284 Validator's hold-down timer keep running without being reset 285 assuming all of the validations succeed (again: the attacker can 286 no longer replay traffic to their benefit). 288 T+30 The Zone Signer knows that this is the first time at which some 289 validators might accept K_new as a new trust anchor, since the 290 hold-down timer of a RFC5011 Validator not under attack that had 291 queried and retrieved K_new at T+0 would now have reached 30 days. 292 However, the hold-down timer of our attacked RFC5011 Validator is 293 only at 20 days. 295 T+35 The Zone Signer (mistakenly) believes that all validators 296 following the Active Refresh schedule (Section 2.3 of RFC5011) 297 should have accepted K_new as a the new trust anchor (since the 298 hold down time of 30 days + 1/2 the signature validity period 299 would have passed). However, the hold-down timer of our attacked 300 RFC5011 Validator is only at 25 days; The replay attack at T+5 301 means its new hold-time timer actually started at T+10, and thus 302 at this time it's real hold-down timer is at T+35 - T+10 = 25 303 days, which is less than the RFC5011 required 30 days and the 304 RFC5011 won't consider it a valid trust anchor addition yet. 306 T+36 The Zone Signer, believing K_new is safe to use, switches their 307 active signing KSK to K_new and publishes a new RRSIG, signed with 308 K_new, and covering the DNSKEY set. Non-attacked RFC5011 309 validators, with a hold-down timer of at least 30 days, would have 310 accepted K_new into their set of trusted keys. But, because our 311 attacked RFC5011 Validator has a hold-down timer for K_new at only 312 26 days, it will fail to accept K_new as a trust anchor. Since 313 K_old is no longer being used, all the DNSKEY records from the 314 zone signed by K_new will be treated as invalid. Subsequently, 315 all keys in the key set are now unusable, invalidating all of the 316 records in the zone of any type and name. 318 6. Minimum RFC5011 Timing Requirements 320 Given the attack description in Section 5, the correct minimum length 321 of time required for the Zone Signer to wait before using K_new is: 323 waitTime = addHoldDownTime 324 + (DNSKEY RRSIG Signature Validity) 325 + MAX(MIN((DNSKEY RRSIG Signature Validity) / 2, 326 MAX(original TTL of K_old DNSKEY RRSet) / 2, 327 15 days), 328 1 hour) 329 + 2 * MAX(TTL of all records) 331 The RFC5011 "Active Refresh" requirements state that: 333 A resolver that has been configured for an automatic update 334 of keys from a particular trust point MUST query that trust 335 point (e.g., do a lookup for the DNSKEY RRSet and related 336 RRSIG records) no less often than the lesser of 15 days, half 337 the original TTL for the DNSKEY RRSet, or half the RRSIG 338 expiration interval and no more often than once per hour. 340 The important timing constraint introduced by this memo relates to 341 the last point at which a validating resolver may have received a 342 replayed the original DNSKEY set (K_old) without the new key. It's 343 the next query of the RFC5011 validator that the assured K_new will 344 be seen without a potential replay afterward. Thus, the latest time 345 a RFC5011 validator may begin their hold down timer is an "Active 346 Refresh" period after the last point that an attacker can replay the 347 K_old DNSKEY set. 349 The "Active Refresh" interval used by a RFC5011 validator is 350 determined by the larger of (DNSKEY RRSIG Signature Validity) and 351 (original TTL for the DNSKEY RRSet). The Following text assumes that 352 (DNSKEY RRSIG Signature Validity) is larger of the two, which is 353 operationally more common today. 355 Thus, the worst case scenario of this attack is when the attacker can 356 replay K_old just before (DNSKEY RRSIG Signature Validity). If a 357 RFC5011 validator picks up K_old at this this point, it will not have 358 a hold down timer started as it will have been reset by previous 359 replays. It's not until the next "Active Refresh" time that they'll 360 pick up K_new with assurance, and thus start their (final) hold down 361 timer. Thus, this is not at (DNSKEY RRSIG Signature Validity) time 362 past publication but may be significantly longer based on the zone's 363 DNSSEC parameters. 365 The extra 2 * MAX(TTL of all records) is the standard added safety 366 margin when dealing with DNSSEC due to caching that can take place. 367 Because the 5011 steps require direct validation using the signature 368 validity, the authors aren't yet convinced it is needed in this 369 particular case, but it is prudent to include it for added assurance. 371 For the parameters listed in Section 5.1, our example: 373 waitTime = 30 374 + 10 375 + 10 / 2 376 + 2 * (1) (days) 378 waitTime = 47 (days) 380 This hold-down time of 47 days is 12 days longer than the (frequently 381 perceived) 35 days in the example at T+35 above. 383 It is important to note that this value affects not just the 384 publication of new DNSKEYs intended to be used as trust anchors, but 385 also the length of time required to publish a DNSKEY with the revoke 386 bit set. Both of these publication timing requirements are affected 387 by the attacks described in this document. 389 7. IANA Considerations 391 This document contains no IANA considerations. 393 8. Operational Considerations 395 A companion document to RFC5011 was expected to be published that 396 describes the best operational practice considerations from the 397 perspective of a zone publisher and Trust Anchor Publisher. However, 398 this companion document has yet to be published. The authors of this 399 document hope that it will at some point in the future, as RFC5011 400 timing can be tricky as we have shown and we do not suggest "good 401 operational practice" that might be associated with a BCP on the 402 subject. This document is intended only to fill a single operational 403 void that results in security ramifications (specifically a denial of 404 service attack against an RFC5011 Validator). This document does not 405 attempt to document any other missing operational guidance for zone 406 publishers. 408 9. Security Considerations 410 This document, is solely about the security considerations with 411 respect to the Trust Anchor Publisher of RFC5011 trust anchors / 412 keys. Thus the entire document is a discussion of Security 413 Considerations when rolling DNSKEYs using the RFC5011 process. 415 10. Acknowledgements 417 The authors would like to especially thank to Michael StJohns for his 418 help and advice and the care and thought he put into RFC5011 itself. 419 We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking, 420 Duane Wessels, Petr Petr Spacek, and the dnsop working group who have 421 assisted with this document. 423 11. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 429 Rose, "DNS Security Introduction and Requirements", 430 RFC 4033, DOI 10.17487/RFC4033, March 2005, 431 . 433 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 434 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 435 September 2007, . 437 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 438 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 439 2015, . 441 Appendix A. Real World Example: The 2017 Root KSK Key Roll 443 In 2017, ICANN expects to (or has, depending on when you're reading 444 this) roll the key signing key (KSK) for the root zone. The relevant 445 parameters associated with the root zone at the time of this writing 446 is as follows: 448 addHoldDownTime: 30 days 449 Old DNSKEY RRSIG Signature Validity: 21 days 450 Old DNSKEY TTL: 2 days 452 Thus, sticking this information into the equation in 453 Section Section 6 yields (in days): 455 waitTime = addHoldDownTime 456 + (DNSKEY RRSIG Signature Validity) 457 + MAX(MIN((DNSKEY RRSIG Signature Validity) / 2, 458 MAX(original TTL of K_old DNSKEY RRSet) / 2, 459 15 days), 460 1 hour) 461 + 2 * MAX(TTL of all records) 463 waitTime = 30 464 + (21) 465 + MAX(MIN((21) / 2, 466 MAX(2 / 2, 467 15 days)), 468 1 hour) 469 + 2 * MAX(2) 471 waitTime = 30 + 21 + MAX(MIN(11.5, MAX( 1, 15)), 1 hour) + 4 473 waitTime = 30 + 21 + 11.5 + 4 475 waitTime = 66.5 days 477 Thus, ICANN should wait 66.5 days before switching to the newly 478 published KSK and before removing the old revoked key once it is 479 published as revoked. ICANN's current plans are to wait 70 days 480 before using the new KEY and 69 days before removing the old, revoked 481 key. Thus, their current rollover plans are sufficiently secure from 482 the attack discussed in this memo. 484 Appendix B. Changes / Author Notes. 486 From Individual-00 to DNSOP-00: 488 o Filename change. 490 From -00 to -01: 492 o Added Revocation processing (including "Timing Associated with 493 Revocation") 495 o Added real world example. 497 o Fixed some typoes and missing references. 499 From Ind-00 to -02: 501 Additional background and clarifications in abstract. 503 Better separation in attack description between attacked and non- 504 attacked resolvers. 506 Some language cleanup. 508 Clarified that this is maths ( and math is hard, let's go 509 shopping!) 511 Changed to " " style references. 513 From -02 to -03: 515 Minor changes from Bob Harold 517 Clarified why 3/2 signature validity is needed 519 Changed min wait time math to include TTL value as well 521 From -03 to -04: 523 Fixed the waitTime equation to handle the difference between the 524 usage of the expiration time and the Active Refresh time. 526 More clarification text and text changes proposed by Petr Spacek 528 From -04 to -05: 530 Clarifications about signing using only new keys, vs old ones too 532 Pre-DNSOP document: From hardaker-04 to ietf-00: 534 Just rebranding. 536 From ietf-00 to ietf-01: 538 Added discussion surrounding revocation everywhere 540 Fixed the text about the formula 542 Another complete re-read for word-smithing 544 Authors' Addresses 545 Wes Hardaker 546 USC/ISI 547 P.O. Box 382 548 Davis, CA 95617 549 US 551 Email: ietf@hardakers.net 553 Warren Kumari 554 Google 555 1600 Amphitheatre Parkway 556 Mountain View, CA 94043 557 US 559 Email: warren@kumari.net