idnits 2.17.1 draft-hardaker-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 : ---------------------------------------------------------------------------- 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 (February 17, 2017) is 2617 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) No issues found here. Summary: 0 errors (**), 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 Parsons, Inc. 4 Intended status: Standards Track W. Kumari 5 Expires: August 21, 2017 Google 6 February 17, 2017 8 Security Considerations for RFC5011 Publishers 9 draft-hardaker-rfc5011-security-considerations-04 11 Abstract 13 This document describes the math behind the minimum time-length that 14 a DNS zone publisher must wait before using a new DNSKEY to sign 15 records when supporting the RFC5011 rollover strategies. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 21, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Timing associated with RFC5011 processing . . . . . . . . . . 3 56 5. Denial of Service Attack Considerations . . . . . . . . . . . 4 57 5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 4 58 5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 5 59 6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 8. Operational Considerations . . . . . . . . . . . . . . . . . 7 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 RFC5011 [RFC5011] defines a mechanism by which DNSSEC validators can 71 extend their list of trust anchors when they've seen a new key 72 published in a zone. However, RFC5011 [intentionally] provides no 73 guidance to the publishers of DNSKEYs about how long they must wait 74 before switching to the newly published key for signing records. 75 Because of this lack of guidance, zone publishers may derive 76 incorrect assumptions about safe usage of the RFC5011 DNSKEY 77 advertising and rolling process. This document describes the minimum 78 security requirements from a publishers point of view and is intended 79 to compliment the guidance offered in RFC5011 (which is written to 80 provide timing guidance solely to the Validating Resolvers point of 81 view). 83 To verify this lack of understanding is wide-spread, the authors 84 reached out to 5 DNSSEC experts to ask them how long they thought 85 they must wait before using a new KSK that was being rolled according 86 to the 5011 process. All 5 experts answered with an insecure value, 87 and thus we have determined that this lack of operational guidance is 88 causing security concerns today. We hope that this document will 89 rectify this understanding and provide better guidance to zone 90 publishers that wish to make use of the RFC5011 rollover process. 92 One important note about ICANN's upcoming 2017 KSK rollover plan for 93 the root zone: the timing values chosen for rolling the KSK in the 94 root zone appear completely safe, and are not in any way affected by 95 the timing concerns introduced by this draft 97 1.1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Background 105 The RFC5011 process describes a process by which a Validating 106 Resolver may accept a newly published KSK as a trust anchor for 107 validating future DNSSEC signed records. This document augments that 108 information with additional constraints, as required from the DNSKEY 109 publication point of view. Note that it does not define any other 110 operational guidance or recommendations about the RFC5011 process 111 from a publication point of view and restricts itself to solely the 112 security and operational ramifications of switching to a new key too 113 soon. Failure of a DNSKEY publisher to follow the minimum 114 recommendations associated with this draft will result in potential 115 denial-of-service attack opportunities against validating resolvers. 117 3. Terminology 119 Trust Anchor Publisher The entity responsible for publishing a 120 DNSKEY that can be used as a trust anchor. 122 4. Timing associated with RFC5011 processing 124 RFC5011's process of safely publishing a new key and then making use 125 of that key falls into a number of high-level steps: 127 1. Publish a new DNSKEY in the zone but continue to sign with the 128 old one. 130 2. Wait a period of time. 132 3. Begin using the new DNSKEY to sign the appropriate resource 133 records. 135 4. Optionally mark the older DNSKEY as revoked and publish the 136 revoked key. 138 This document discusses step 2 of the above process. Some 139 interpretations of RFC5011 have erroneously determined that the wait 140 time is equal to RFC5011's "hold down time". 142 This document describes an attack based on this (common) erroneous 143 belief, which results in a denial of service attack against the zone 144 if that value is used. 146 5. Denial of Service Attack Considerations 148 If an attacker is able to provide a RFC5011 validating engine with 149 past responses, such as when it is in-path or able to otherwise 150 perform any number of cache poisoning attacks, the attacker may be 151 able to leave the RFC5011-compliant validator without an appropriate 152 DNSKEY trust anchor. This scenario will remain until an 153 administrator manually fixes the situation. 155 The following timeline illustrates this situation. 157 5.1. Enumerated Attack Example 159 The following example settings are used in the example scenario 160 within this section: 162 TTL (all records) 1 day 164 DNSKEY RRSIG Signature Validity 10 days 166 Zone resigned every 1 day 168 Given these settings, the following sequence of events depicts how a 169 Trust Anchor Publisher that waits for only the RFC5011 hold time 170 timer length of 30 days subjects its users to a potential Denial of 171 Service attack. The timing schedule listed below is based on a new 172 trust anchor (a Key Signing Key (KSK)) being published at time T+0. 173 All numbers in this sequence refer to days before and after such an 174 event. Thus, T-1 is the day before the introduction of the new key, 175 and T+15 is the 15th day after the key was introduced into the 176 fictitious zone being discussed. 178 In this dialog, we consider two keys being published: 180 K_old The older KSK being replaced. 182 K_new The new KSK being transitioned into active use, using the 183 RFC5011 process. 185 In this dialog, the following actors are playing roles in this 186 situation: 188 Zone Signer The owner of a zone intending to publish a new Key- 189 Signing-Key (KSK) that will become a trust anchor by validators 190 following the RFC5011 process. 192 RFC5011 Validator A DNSSEC validator that is using the RFC5011 193 processes to track and update trust anchors. 195 Attacker An attacker intent on foiling the RFC5011 Validator's 196 ability to successfully adopt the Zone Signer's K_new key as a new 197 trust anchor. 199 5.1.1. Attack Timing Breakdown 201 The following series of steps depicts the timeline in which an attack 202 occurs that foils the adoption of a new DNSKEY by a Trust Anchor 203 Publisher that revokes the old key too quickly. 205 T-1 The last signatures are published by the Zone Signer that signs 206 only K_old using K_old. The Attacker queries for, retrieves and 207 caches this keyset and corresponding signatures. 209 T-0 The Zone Signer adds K_new to his zone and signs the zone's key 210 set with K_old. The RFC5011 Validator retrieves the new key set 211 and corresponding signature set and notices the publication of 212 K_new. The RFC5011 Validator starts the (30-day) hold-down timer 213 for K_new. 215 T+5 The RFC5011 Validator queries for the zone's keyset per the 216 Active Refresh schedule, discussed in Section 2.3 of RFC5011. 217 Instead of receiving the intended published keyset, the Attacker 218 successfully replays the keyset and associated signatures that 219 they recorded at T-1. Because the signature lifetime is 10 days 220 (in this example), the replayed signature and keyset is accepted 221 as valid (being only 6 days old) and the RFC5011 Validator cancels 222 the hold-down timer for K_new. 224 T+10 The RFC5011 Validator queries for the zone's keyset and 225 discovers K_new again, signed by K_old (the attacker is unable to 226 replay the records cached at T-1, because they have now expired). 227 The RFC5011 Validator starts (anew) the hold-timer for K_new. 229 T+15,T+20, and T+25 The RFC5011 Validator continues checking the 230 zone's key set and lets the hold-down timer keep running without 231 resetting it. 233 T+30 The Zone Signer knows that this is the first time at which some 234 validators might accept K_new as a new trust anchor, since the 235 hold-down timer of a RFC5011 Validator not under attack that had 236 queried and retrieved K_new at T+0 would now have reached 30 days. 237 However, the hold-down timer of our attacked RFC5011 Validator is 238 only at 20 days. 240 T+35 The Zone Signer (mistakenly) believes that all validators 241 following the Active Refresh schedule (Section 2.3 of RFC5011) 242 should have accepted K_new as a the new trust anchor (since the 243 hold down time of 30 days + 1/2 the signature validity period 244 would have passed). However, the hold-down timer of our attacked 245 RFC5011 Validator is only at 25 days; The replay attack at T+5 246 means its new hold-time timer actually started at T+10, and thus 247 at this time it's real hold-down timer is at T+35 - T+10 = 25 248 days, which is less than the RFC5011 required 30 days. 250 T+36 The Zone Signer, believing K_new is safe to use, switches their 251 active signing KSK to K_new and publishes a new DNSKEY set 252 signature signed with K_new. Non-attacked RFC5011 validators, 253 with a hold-down timer of at least 30 days, would have accepted 254 K_new into their set of trusted keys. But, because our attacked 255 RFC5011 Validator still has a hold-down timer for K_new at 26 256 days, it will fail to accept K_new as a trust anchor and since 257 K_old is no longer being used, all the KSK records from the zone 258 signed by K_new will be treated as invalid. Subsequently, all 259 keys in the key set are now unusable, invalidating all records in 260 the zone of any type and name. 262 6. Minimum RFC5011 Timing Requirements 264 Given the attack description in Section 5, the correct minimum length 265 of time required for the Zone Signer to wait before using K_new is: 267 waitTime = addHoldDownTime 268 + (DNSKEY RRSIG Signature Validity) 269 + MAX(MIN((DNSKEY RRSIG Signature Validity) / 2, 270 MAX(original TTL of K_old DNSKEY RRSet) / 2, 271 15 days), 272 1 hour) 273 + 2 * MAX(TTL of all records) 275 The most confusing element of the above equation comes from the "3 * 276 (DNSKEY RRSIG Signature Validity) / 2" element, but is the most 277 critical to understand and get right. 279 The RFC5011 "Active Refresh" requirements state that: 281 A resolver that has been configured for an automatic update 282 of keys from a particular trust point MUST query that trust 283 point (e.g., do a lookup for the DNSKEY RRSet and related 284 RRSIG records) no less often than the lesser of 15 days, half 285 the original TTL for the DNSKEY RRSet, or half the RRSIG 286 expiration interval and no more often than once per hour. 288 The important timing constraint that must be considered is the last 289 point at which a validating resolver may have received a replayed the 290 original DNSKEY set (K_old) without the new key. It's the next query 291 of the RFC5011 validator that the assured K_new will be seen. Thus, 292 the latest time a RFC5011 validator may begin their hold down timer 293 is an "Active Refresh" period after the last point that an attacker 294 can replay the K_old DNSKEY set. 296 The "Active Refresh" interval used by RFC5011 validator is determined 297 by the larger of (DNSKEY RRSIG Signature Validity) and (original TTL 298 for the DNSKEY RRSet). The Following text assumes that (DNSKEY RRSIG 299 Signature Validity) is larger of the two, which is operationally more 300 common today. 302 Thus, the worst case scenario of this attack is when the attacker can 303 replay K_old at just before (DNSKEY RRSIG Signature Validity). If a 304 RFC5011 validator picks up K_old at this this point, it will not have 305 a hold down timer started at all. It's not until the next "Active 306 Refresh" time that they'll pick up K_new with assurance, and thus 307 start their hold down timer. Thus, this is not at (DNSKEY RRSIG 308 Signature Validity) time past publication, but rather 3 * (DNSKEY 309 RRSIG Signature Validity) / 2. 311 The extra 2 * MAX(TTL of all records) is the standard added safety 312 margin when dealing with DNSSEC due to caching that can take place. 313 Because the 5011 steps require direct validation using the signature 314 validity, the authors aren't yet convinced it is needed in this 315 particular case. 317 For the parameters listed in Section 5.1, our example: 319 waitTime = 30 320 + 10 321 + 10 / 2 322 + 2 * (1) (days) 324 waitTime = 47 (days) 326 This hold-down time of 47 days is 12 days longer than the frequently 327 perceived 35 days in T+35 above. 329 7. IANA Considerations 331 This document contains no IANA considerations. 333 8. Operational Considerations 334 A companion document to RFC5011 was expected to be published that 335 describes the best operational practice considerations from the 336 perspective of a zone publisher and Trust Anchor Publisher. However, 337 this companion document was never written. The authors of this 338 document hope that it will at some point in the future, as RFC5011 339 timing can be tricky as we have shown. This document is intended 340 only to fill a single operational void that results in security 341 ramifications (specifically a denial of service attack against an 342 RFC5011 Validator). This document does not attempt to document any 343 other missing operational guidance for zone publishers. 345 9. Security Considerations 347 This document, is solely about the security considerations with 348 respect to the Trust Anchor Publisher of RFC5011 trust anchors / 349 keys. Thus the entire document is a discussion of Security 350 Considerations 352 10. Acknowledgements 354 The authors would like to especially thank to Michael StJohns for his 355 help and advice. We would also like to thank Bob Harold, Shane Kerr, 356 Matthijs Mekking, Duane Wessels, Petr Spaček, and everyone else 357 who assisted with this document. 359 11. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 363 RFC2119, March 1997, 364 . 366 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 367 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 368 September 2007, . 370 Appendix A. Changes / Author Notes. 372 From -00 to -02: 374 Additional background and clarifications in abstract. 376 Better separation in attack description between attacked and non- 377 attacked resolvers. 379 Some language cleanup. 381 Clarified that this is maths ( and math is hard, let's go 382 shopping!) 384 Changed to " " style references. 386 From -02 to -03: 388 Minor changes from Bob Harold 390 Clarified why 3/2 signature validity is needed 392 Changed min wait time math to include TTL value as well 394 From -03 to -04: 396 Fixed the waitTime equation to handle the difference between the 397 usage of the expiration time and the Active Refresh time. 399 More clarification text and text changes proposed by Petr 400 Spaček 402 Authors' Addresses 404 Wes Hardaker 405 Parsons, Inc. 406 P.O. Box 382 407 Davis, CA 95617 408 US 410 Email: ietf@hardakers.net 412 Warren Kumari 413 Google 414 1600 Amphitheatre Parkway 415 Mountain View, CA 94043 416 US 418 Email: warren@kumari.net