idnits 2.17.1 draft-morris-dnsop-dnssec-key-timing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 15, 2009) is 5300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Morris 3 Internet-Draft Nominet 4 Intended status: Informational J. Ihren 5 Expires: April 18, 2010 Autonomica 6 J. Dickinson 7 October 15, 2009 9 DNSSEC Key Timing Considerations 10 draft-morris-dnsop-dnssec-key-timing-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 18, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document describes the issues surrounding the timing of events 49 in the rolling of a key in a DNSSEC-secured zone. It presents 50 timlines for the key rollover and explicitly identifies the 51 relationships between the various parameters affecting the process. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 2. Types of Key Rollover . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Pre-Publication Method . . . . . . . . . . . . . . . . . . 4 60 2.2. Double-Signature Method . . . . . . . . . . . . . . . . . 5 61 2.3. Comparison of Rollover Methods . . . . . . . . . . . . . . 5 62 2.4. Timing Considerations . . . . . . . . . . . . . . . . . . 5 63 3. Zone-Signing Keys . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Key States . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.3. Stand-By Zone-Signing Keys . . . . . . . . . . . . . . . . 10 67 3.3.1. Stand-By Key Scheduling . . . . . . . . . . . . . . . 10 68 3.3.2. Number of Stand-By Keys . . . . . . . . . . . . . . . 11 69 4. Key-Signing Keys . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2. Parent Zone Considerations . . . . . . . . . . . . . . . . 13 72 4.3. Rollover Strategies . . . . . . . . . . . . . . . . . . . 14 73 4.4. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.5. Key States . . . . . . . . . . . . . . . . . . . . . . . . 19 75 4.6. Stand-By Key-Signing Keys . . . . . . . . . . . . . . . . 19 76 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 19 77 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 81 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 20 82 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 83 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 86 1. Introduction 88 When a zone is secured with DNSSEC, the zone manager must be prepared 89 to replace ("roll") the keys used in the signing process. The 90 rolling of keys may be caused by compromise of one or more of the 91 existing keys, or it may be due to a management policy that demands 92 periodic key replacement for security reasons. In order to implement 93 a key rollover, the keys need to introduced into and removed from the 94 zone at the appropriate times. Considerations that must be taken 95 into account are: 97 o Key and signature records are not only held at the authoritative 98 nameserver; they are also cached at client resolvers. The data on 99 these systems can be interlinked, e.g. a validator may try to 100 validate a signature retrieved from a cache with a key obtained 101 separately. 103 o To allow for an emergency re-signing of the zone as soon as 104 possible after a key compromise has been detected, stand-by keys 105 (additional keys over and above those used to sign the zone) need 106 to be present. 108 o A query for the key RRset returns all DNSKEY records in the zone. 109 As there is limited space in the UDP packet (even with EDNS0 110 support), dead key records must be periodically removed. (For the 111 same reason, the number of stand-by keys in the zone should be 112 restricted to the minimum required to support the key management 113 policy.) 115 o Zone "boot-strapping" events, where a zone is signed for the first 116 time, can be common in configurations where a large number of 117 zones are being served. Procedures should be able to cope with 118 the introduction of keys into the zone for the first time as well 119 as "steady-state", where the records are being replaced as part of 120 normal zone maintenance. 122 Management policy, e.g. how long a key is used for, also needs to be 123 taken into account. However, the point of key management logic is 124 not to ensure that a "rollover" is completed at a certain time but 125 rather to ensure that no changes are made to the state of keys 126 published in the zone until it is "safe" to do so. In other words, 127 although key management logic enforces policy, it may not enforce it 128 strictly. 130 1.1. Terminology 132 The terminology used in this document is as defined in [RFC4033] and 133 [RFC5011]. 135 A large number of symbols are used in this document to identify 136 times, intervals, etc. All are listed in Appendix A. 138 1.2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Types of Key Rollover 146 As noted in the introduction, client resolvers may cache both key and 147 signature RRsets. This means that when validating a signature record 148 (or passing both RRsets to a client who has issued a query with the 149 CD bit set), an RRSIG just read from an authoritative server may be 150 paired with a cached DNSKEY or vice-versa. For the validation to be 151 successful, the DNSKEY and RRSIG must be consistent. 153 Key rollover - the replacement of the key use to sign the zone with 154 another - involves changing the contents of the DNSKEY RRset and re- 155 signing the zone (so changing the RRSIG records). In order for a RR 156 to be validated, at least one RRSIG in the associated signature RRset 157 must be able to be validated by one of the keys in the DNSKEY RRset. 158 To ensure uninterrupted security, the aim must be to ensure that this 159 condition is true at all stages during the rollover process. 161 Two ways to achieve this goal are the pre-publication method and the 162 double signature method. 164 2.1. Pre-Publication Method 166 In pre-publication, the new key is introduced into the DNSKEY RRset, 167 leaving the existing keys and signatures in place. This state of 168 affairs remains in place for long enough to ensure that any DNSKEY 169 RRsets cached in client resolvers contain both keys. At that point, 170 the zone can be signed with the new key and the old signatures 171 removed. During the re-signing process (which may or may not be 172 atomic depending on how the zone is managed), it doesn't matter which 173 key an RRSIG record retrieved by a client was created with; clients 174 will have a copy of the DNSKEY RRset containing both the old and new 175 keys. 177 Once the zone contains only signatures created with the new key, 178 there is an interval during which RRSIG records created with the old 179 key expire from client caches. After this, the old key can be 180 removed from the DNSKEY RRset because there will be no signatures 181 anywhere created using it. 183 2.2. Double-Signature Method 185 Double-signature, as the name implies, involves introducing the new 186 key into the zone and using it to create additional RRSIG records; 187 the old key and existing RRSIG records are retained. During the 188 period in which the zone is being signed (again, the signing process 189 may not be atomic), client resolvers are always able to validate 190 RRSIGs: any combination of old and new DNSKEY and RRSIG RRsets allows 191 at least one signature to be validated. 193 Once the signing process is complete and enough time has elapsed to 194 allow all old DNSKEY and RRSIG RRsets to expire from caches, the old 195 key and signatures can be removed from the zone. As before, during 196 this period any combination of DNSKEY and RRSIG RRsets will allow 197 validation of at least one signature. 199 2.3. Comparison of Rollover Methods 201 Of the two methods, double-signature is the simplest conceptually - 202 introduce the new key and new signatures, then (roughly) one TTL 203 later remove the old key and signatures. The drawback of this method 204 is a noticeable increase in the size of the DNSSEC data. This 205 affects both the overall size of the zone and the size of the 206 responses. 208 Pre-publication is more complex - introduce the new key, one TTL 209 later sign the records, and one TTL after that remove the old key. 210 However, the amount of DNSSEC data is kept to a minimum, hence 211 reducing the impact on performance. 213 2.4. Timing Considerations 215 The rest of this paper describes the timing considerations related to 216 the rolling of zone-signing keys (ZSKs) and key-signing keys (KSKs). 217 Owing to the increase in the amount of DNSSEC data in the double- 218 signature method, the pre-publication approach is preferred for 219 rollover of ZSKs. However, in the case of KSK rollovers, the size 220 increase is negligible and hence the complexity of pre-publication is 221 not justified. 223 While this combination is the most common choice of rollover logic, 224 there is nothing to preclude other combinations should the situation 225 demand it. The rest of this document describes ZSK and KSK rollover 226 timelines for the common case. 228 3. Zone-Signing Keys 230 3.1. Key Timeline 232 The following diagram shows the time line of a particular ZSK (zone- 233 signing key) and its replacement by its successor. Time increases 234 along the horizontal scale from left to right and the vertical lines 235 indicate events in the life of the key. The events are numbered; 236 significant times and time intervals are marked. 238 |1| |2| |3| |4| |5| |6| |7| |8| |9| 239 | | | | | | | | | 240 Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| 241 | | | | | | | | | 242 Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - 243 | | | | | | | | | 244 Tgen Tpub Trdy Tact TpubS Tret Tdea Trem 246 ---- Time ----> 248 Figure 1: Timeline for a ZSK rollover. 250 Event 1: key N is generated at the generate time (Tgen). Although 251 there is no reason why the key cannot be generated immediately prior 252 to publication in the zone (Event 2), some implementations may find 253 it convenient to create a pool of keys in one operation and draw from 254 that pool as required. For this reason, it is shown as a separate 255 event. Keys that are available for use but not published are said to 256 be generated. 258 Event 2: key N's DNSKEY record is put into the zone, i.e. it is added 259 to the DNSKEY RRset which is then re-signed with the current key- 260 signing key. The time at which this occurs is the key's publication 261 time (Tpub), and the key is now said to be published. Note that key 262 N is not yet used to sign records. 264 Event 3: before it can be used, the key must be published for long 265 enough to guarantee that any resolver that has a copy of the DNSKEY 266 RRset from the zone in its cache will have a copy of the RRset that 267 includes this key: in other words, that any prior cached information 268 about the DNSKEY RRset has expired. 270 The interval is the publication interval (Ipub) and, for the second 271 or subsequent keys in the zone, is given by: 273 Ipub = Dprp + TTLkey 275 Here, Dprp is the propagation delay - the time take for any change 276 introduced at the master to replicate to all slave servers - which 277 depends on the depth of the master-slave hierarchy. TTLkey is the 278 time-to-live (TTL) for the DNSKEY records in the zone. The sum is 279 therefore the time taken for existing DNSKEY records to expire from 280 the caches of downstream validators, regardless of the nameserver 281 from which they were retrieved. 283 In the case of the first key in the zone, Ipub is slightly different 284 because it is not information about a DNSKEY RRset that may be 285 cached, it is information about its absence. In this case: 287 Ipub = Dprp + Ingc 289 where Ingc is the negative cache interval from the zone's SOA record, 290 calculated according to [RFC2308] as the minimum of the TTL of the 291 SOA record itself (TTLsoa), and the "minimum" field in the record's 292 parameters (SOAmin), i.e. 294 Ingc = min(TTLsoa, SOAmin) 296 After a delay of Ipub, the key is said to be ready and can be used to 297 sign records. The time at which this event occurs is the key's ready 298 time (Trdy), which is given by: 300 Trdy = Tpub + Ipub 302 Event 4: at some later time, the key starts being used to sign 303 RRsets. This point is the activation time (Tact) and after this, the 304 key is said to be in the active state. 306 Event 5: while this key is active, thought must be given to its 307 successor. As with the introduction of the currently active key into 308 the zone, the successor key will need to be published at least Ipub 309 before it is used. Denoting the publication time of the successor 310 key by TpubS, then: 312 TpubS <= Tact + Lzsk - Ipub 314 Here, Lzsk is the length of time for which a ZSK will be used (the 315 ZSK lifetime). It should be noted that unlike the publication 316 interval, Lzsk is not determined by timing logic, but by key 317 management policy. Lzsk will be set by the operator according to 318 their assessment of the risks posed by continuing to use a key and 319 the risks associated with key rollover. However, operational 320 considerations may mean a key lives for slightly more or less than 321 Lzsk. 323 Event 6: while the current ZSK is still active, its successor becomes 324 ready. From this time onwards, it could be used to sign the zone. 326 Event 7: at some point the decision is made to start signing the zone 327 using the successor key. This will be when the current key has been 328 in use for an interval equal to the ZSK lifetime, hence: 330 Tret = Tact + Lzsk 332 This point in time is the retire time (Tret) of key N; after this the 333 key is said to be retired. (This time is also the point at which the 334 successor key becomes active.) 336 Event 8: the retired key needs to be retained in the zone whilst any 337 RRSIG records created using this key are still published in the zone 338 or held in resolver caches. (It is possible that a resolver could 339 have an unexpired RRSIG record and an expired DNSKEY RRset in the 340 cache when it is asked to provide both to a client. In this case the 341 DNSKEY RRset would need to be looked up again.) This means that once 342 the key is no longer used to sign records, it should be retained in 343 the zone for at least the retire interval (Iret) given by: 345 Iret = Dsgn + Dprp + TTLsig 347 Dsgn is the delay needed to ensure that all existing RRsets have been 348 re-signed with the new key. Dprp is (as described above) the 349 propagation delay, required to guarantee that the updated zone 350 information has reached all slave servers, and TTLsig is the TTL of 351 the RRSIG records. 353 (It should be noted that an upper limit on the retire interval is 354 given by: 356 Iret = Lsig + Dskw 358 where Lsig is the lifetime of a signature (i.e. the interval between 359 the time the signature was created and the signature end time), and 360 Dskw is the clock skew - the maximum difference in time between the 361 server and a validator. The reasoning here is that whatever happens, 362 a key only has to be available while any signatures created with it 363 are valid. Wherever a signature record is held - published in the 364 zone and/or held in a resolver cache - it won't be valid for longer 365 than Lsig after it was created. The Dskw term is present to account 366 for the fact that the signature end time is an absolute time rather 367 than interval, and systems may not agree exactly about the time.) 368 The time at which all RRSIG records created with this key expire from 369 resolver caches is the dead time (Tdea), given by: 371 Tdea = Tret + Iret 373 Event 9: at any time after the key becomes dead, it can be removed 374 from the zone and the DNSKEY RRset re-signed with the current key- 375 signing key. This time is the removal time (Trem), given by: 377 Trem >= Tdea 379 ...and the key is said to be in the removed state. 381 3.2. Key States 383 An alternative way of considering the key timeline is to regard the 384 key as moving through a set of states, the state transitions being 385 determined by time. The state transition diagram is linear and is 386 shown in Figure 2: 388 +-----------+ +-----------+ +-----------+ 389 Start ---->| Generated |----->| Published |----->| Ready | 390 Tgen +-----------+ Tpub +-----------+ Trdy +-----------+ 391 | 392 +-----------+ | 393 +------------| Active |<-----------+ 394 | Tret +-----------+ Tact 395 V 396 +-----------+ +-----------+ +-----------+ 397 | Retired |----->| Dead |----->| Removed | 398 +-----------+ Tdea +-----------+ Trem +-----------+ 400 Figure 2: ZSK State Diagram. 402 The states are: 404 Generated The key has been created. 406 Published The DNSKEY record is published in the zone, but resolvers 407 may have earlier versions of the DNSKEY RRset in their 408 cache. 410 Ready The key has been published for long enough to guarantee 411 that all cached versions of the zone's DNSKEY RRset 412 contain this key. 414 Active The key is in the zone and is being used to sign RRsets. 416 Retired The key is in the zone but is no longer being used to 417 sign RRsets. However, there may still be RRSIG records 418 in caches that were created with this key. 420 Dead The key is published in the zone but there are no RRSIGs 421 in existence created with this key. 423 Removed The key has been removed from the zone. 425 3.3. Stand-By Zone-Signing Keys 427 Although ZSKs will usually be rolled according to some regular 428 schedule, there may be occasions when an emergency ZSK rollover is 429 required, e.g. if the active key is suspected of being compromised. 430 The aim of the emergency rollover is to allow the zone to be re- 431 signed with a new key as soon as possible. As a key must be in the 432 ready state to sign the zone, having at at least one stand-by ZSK in 433 this state at all times will minimise delay. 435 3.3.1. Stand-By Key Scheduling 437 One way to achieve this is to regard successor keys as stand-by keys 438 for emergency rollovers and to introduce them in the zone as early as 439 possible. A modification of Figure 1 illustrates this: 441 |1| |2| |3| |4| 442 | | | | 443 Key N - - - -----Lzsk---------->| | 444 | | | | 445 Key N+1 - --------------------->|<----Lzsk----->| 446 | | | | 447 Key N+2 |<-Ipub->|<---------------------->|<--Lzsk-- - - 448 | | | | 450 ---- Time ----> 452 Figure 3: Timeline showing stand-by key replacement. 454 In this figure, it is assumed that key N is initially in the active 455 state and that key N+1 is in the ready state. Key N+1 is the 456 successor to key N but is regarded as the stand-by key for an 457 emergency re-signing until the time comes to use it to sign the zone. 459 Event 1: At least Ipub before key N's retire time, key N+2 is 460 published in the zone. 462 Event 2: key N+2 moves into the ready state. 464 Event 3: key N is retired and key N+1 becomes active (as described in 465 Section 3.1, events 7 - 9). Key N+2 is now regarded as the stand-by 466 key. 468 Event 4: key N+1 is retired and key N+2 becomes the current key. By 469 this time, key N+3 will have been published and be in the ready 470 state. 472 The above illustrates one way of handling stand-by keys for emergency 473 use. An equally valid alternative would be to have a permanent 474 stand-by key. In this scheme, a key is published in the zone but, 475 unless it needs to be used in an emergency, is never used to sign it. 476 Instead, active keys are replaced by their successors as shown in 477 Figure 1. 479 3.3.2. Number of Stand-By Keys 481 An emergency key rollover could be required at any time. Referring 482 back to Figure 3, should an emergency rollover be required between 483 events 2 and 3, the sequence would happen as previously described: 484 there is a already key (key N+2) ready to take over as the stand-by 485 key when the current stand-by key becomes active. In the worst case 486 though, it may be required that the system run without an stand-by 487 key for a while. For example, if a key rollover was required between 488 events 3 and 4 in Figure 3, the timeline would look like: 490 |3a| |3b| 491 | | 492 Key N+1 - ---Lzsk--->| | 493 | | 494 Key N+2 - ---------->|<----------Lzsk---- - - 495 | | 496 Key N+3 |<-Ipub->|<-------- - - 497 | | 499 ---- Time ----> 501 Figure 4: Timeline showing emergency key rollover. 503 (The interval shown above lies between events 3 and 4 in Figure 3, 504 the events being labelled 3a and 3b to highlight this.) 506 Here it is assumed that key N+1 is initially in the active state and 507 that the single stand-by key (N+2) is in the ready state. It is well 508 before the active key's retire time, so there are only these two ZSKs 509 in the zone. The events are: 511 Event 3a: an emergency ZSK rollover is required. Key N+1 is retired 512 and key N+2 becomes active. At this time, key N+3 (which will 513 ultimately become the new stand-by key) is published in the zone. 515 Event 3b: key N+3 moves into the ready state, after which it can be 516 used to replace key N+1 should the need arise. 518 Between events 3a and 3b however, only the active key (key N+2) can 519 be used to sign the zone. If a second emergency arises in this 520 interval, the active key cannot be replaced: key rollover must wait 521 until the new stand-by key (N+3) becomes ready. Of course, this can 522 be mitigated by having a number of stand-by keys available, but how 523 many is a matter of policy; there is a need to weigh the likelihood 524 of a key compromise against the number of keys required. 526 4. Key-Signing Keys 528 4.1. Introduction 530 There are three significant differences between key-signing keys 531 (KSKs) and ZSKs: 533 1. In the ZSK case the issue for the validator is to ensure that it 534 has access to the ZSK that corresponds to a particular signature. 535 In the KSK case this can never be a problem as the KSK and the 536 signature travel together. Instead, the issue is to ensure that 537 the KSK is trusted. 539 Trust in the KSK is either due to the existence of a DS record in 540 the parent (which is itsef trusted), or the KSK being explicitly 541 configured as a trust anchor for the validator. Hence the 542 additional two differences: 544 2. A KSK rollover algorithm may need to involve the parent zone in 545 the addition and removal of DS records. 547 3. KSKs may be configured as so-called "trust anchors" in validating 548 resolvers. 550 These differences have the following implications for KSK rollovers: 552 1. The rollover logic must ensure that validators are able to 553 validate the DNSKEY RRset throughout the rollover process - 554 either through updates to the chain of trust from the parent zone 555 or through updates to the trust anchor configuration. 557 2. Timings are not wholly within the control of the zone manager, in 558 that the time taken to publish the DS records depends on the 559 policies and procedures of the parent zone. A consequence of 560 this is that the interdependence of the parent DS and child 561 DNSKEY records means that when a new key is introduced, for a 562 period downstream validators might have inconsistent data, i.e. 563 the DS record without the DNSKEY record or vice-versa. Although 564 this is valid state according to [RFC4035], the information 565 cannot be used for validation until the validator has both 566 components. 568 3. Securely removing such KSKs from the zone requires a mechanism 569 for communicating this information to any validators that may 570 have the KSK configured as a trust-anchor. The typical method 571 would be by publishing the revoked key as described in [RFC5011]. 573 There are some differences in the sequence of events between the 574 cases of a zone where a KSK is authenticated via a DS record in the 575 parent zone and one where it is authenticated by a trust anchor 576 configured into a validator. These will be highlighted as 577 appropriate. 579 4.2. Parent Zone Considerations 581 If (as is the usual case) the parent and child zones are managed by 582 different entities, the timing of some of the steps in the KSK 583 rollover operation may be subject to uncertainty. 585 It is important to note that this does not preclude the development 586 of key rollover logic; in accordance with the goal of the rollover 587 logic being able to determine when a state change is "safe", the only 588 effect of being dependent on the parent is that there may be a period 589 of waiting for the parent to respond, in addition to any delay the 590 key rollover logic requires. 592 Although this introduces additional delays, even with a parent that 593 is less than ideally responsive the only effect will be a slowdown in 594 the rollover state transitions. This may cause a policy violation, 595 but will not cause any operational problems. 597 4.3. Rollover Strategies 599 When the parent zone is secured, there are several different ways to 600 roll a KSK whilst ensuring that the zones do not go insecure or bogus 601 in the process: 603 o Double KSK: the new KSK is added to the DNSKEY RRset which is then 604 signed with both the old and new key. After waiting for the old 605 DNSKEY RRset to expire from caches, the DS record in the parent 606 zone is changed. After waiting a further interval for this change 607 to be reflected in validator caches, the old key is removed from 608 the DNSKEY RRset. 610 o Double DS: the new DS record is published. After waiting for this 611 change to propagate into the caches of all validators, the KSK is 612 changed. After a further interval during which the old DNSKEY 613 RRset expires from caches, the old DS record is removed. 615 o Double RRset: the new KSK is added to the DNSKEY RRset which is 616 then signed with both the old and new key, and the new DS record 617 added to the parent zone. After waiting a suitable interval for 618 the old DS and DNSKEY RRsets to expire from validator caches, the 619 old DNSKEY and DS record are removed. 621 In essence, "Double KSK" means that the new KSK is introduced first, 622 and then the new DS (for this KSK). With "Double DS" it is the other 623 way around. Finally, Double RRset does both updates more or less in 624 parallel. 626 Of the three methods, the double RRset method is preferred because: 628 o It allows the rollover to be done in the shortest time. 630 o It can support policies that require a period of running with old 631 and new KSKs simultaneously. 633 4.4. Key Timeline 635 The timeline for the key rollover is shown below: 637 |1| |2| |3| |4| |5| |6| |7| |8| 638 | | | | | | | | 639 Key N | |<-Ipub->|<-->|<-------Lksk------->|<-Iret->| 640 | | | | | | | | 641 Key N+1 | | | | |<-Ipub->|<--->|<---Lksk-- - - 642 | | | | | | | | 643 Tgen Tpub Trdy Tact TpubS TrdyS Tret Trem 645 ---- Time ----> 647 Figure 5: Timeline for a KSK rollover. 649 Event 1: key N is generated at time Tgen and enters the generate 650 state. As before, although there is no reason why the key cannot be 651 generated immediately prior to publication, some implementations may 652 find its convenient to create a central pool of keys and draw from 653 it. For this reason, it is again shown as a separate event. 655 Event 2: the key is added to and used for signing the DNSKEY RRset 656 and is thereby published in the zone. At this time the corresponding 657 DS record is made available. If the parent zone is secure, this 658 means submitting the DS record to the parent zone for publication; if 659 not, it is distributed by some mechanism to allow validators to 660 configure it as a trust anchor. This time is the publish time (Tpub) 661 and the KSK is said to be in the published state. 663 Event 3: after some time (the publication interval, Ipub), any 664 validator that has copies of the DNSKEY and/or DS RRsets in its cache 665 will have a copy of the data for key N. This point is the ready time 666 and is given by: 668 Trdy = Tpub + Ipub 670 Regarding the associated DS record, there are now two cases to 671 consider, where the parent is signed and where the parent is not 672 signed: 674 Event 3 (parent signed): In the case of the KSK, the publication 675 interval depends on the publication interval of both the DNSKEY 676 record and the DS record. These are independent, so a suitable 677 expression for Ipub is: 679 Ipub = max(IpubC, IpubP) 681 IpubC is the publication interval in the child zone and IpubP that of 682 the parent. 684 The child term comprises two parts - the time taken for the 685 introduction of the DNSKEY record to be registered on the downstream 686 secondary servers (= DprpC, the child propagation delay) and the time 687 taken for information about the DNSKEY RRset to expire from the 688 validator cache, i.e. 690 IpubC = DprpC + TTLkeyC 692 (TTLkeyC is the TTL for a DNSKEY record in the child zone.) 694 The parent term is similar, but also includes the time taken for the 695 DS record to be included in the parent zone after the request has 696 been made. In other words: 698 IpubP = Dreg + DprpP + TTLds 700 Dreg is the registration delay, which is the time taken between the 701 submission of the DS record to the parent zone and its publication in 702 the zone. DprpP the propagation delay in the parent zone and TTLds 703 the TTL for a DS record. 705 Throughout the introduction of the two RRs, the zone can be validated 706 by by the existing KSK and DS record. However, there are special 707 considerations regarding the first KSK in a zone, and these are 708 discussed below. 710 Event 3 (parent not signed): if the parent is not signed then there 711 is no parent publication interval (theoretically the DS record could 712 be configured in a validator immediately it is made available), in 713 which case the minimumn value of the publication interval is given 714 by: 716 Ipub = IpubC 718 Event 3 (common): In both cases, if the management policy is to 719 support [RFC5011], there is also the additional condition that the 720 new key needs to be published for at least as long as the RFC5011 add 721 hold-down time, defined in that document as "30 days or the 722 expiration time of the original TTL of the first trust point DNSKEY 723 RRSet that contained the new key, whichever is greater". 725 This can be expressed as the condition: 727 Ipub >= max(30 days, TTLkey) 729 At Trdy, as the key has already been used to sign the DNSKEY RRset, 730 the key is also active in that all other KSKs could be withdrawn from 731 the zone at this point and the zone would still be valid. However, 732 while a predecessor key is active, it is convenient to regard the 733 successor key as merely being ready. 735 Event 4: at some later time, the predecessor key is withdrawn from 736 the zone and, in the absence of any emergency keys, key N becomes the 737 only KSK for the zone. The key is said to be active, and this time 738 is the active time (Tact). 740 Event 5: as with the ZSK, at some point we need to give thought to 741 key replacement. The successor key must be introduced into the zone 742 at a time such that when the current key is withdrawn, any validator 743 that has key information (DNSKEY and/or DS records) in its cache will 744 have data about the successor key. 746 As before, this interval is the publication interval, Ipub. Denoting 747 the publication time of the successor key as TpubS, we get: 749 TpubS <= Tact + Lksk - Ipub 751 ... where Lksk is the lifetime of the KSK. 753 Event 6: the successor key (key N+1) enters the ready state. This 754 occurs at TrdyS, given by: 756 TrdyS = TpubS + Ipub 758 Event 7: at some time after that a decision will be made to retire 759 the current key (key N). This will be when the current key has been 760 active for its lifetime (Lksk). At this point, the retire time, the 761 successor key becomes active and the current key is said to be 762 retired: 764 Tret = Tact + Lksk 766 (... with the obvious condition that Tret >= TrdyS.) 768 If the management policy is to support [RFC5011], the retired key 769 should now have the revoke bit set and be included in the DNSKEY 770 RRset. the revoked key should also be used to sign it. 772 Event 8: at some later time, the DNSKEY record can be removed from 773 the child zone. If there is a secure parent, a request can be made 774 to remove the DS record from the parent zone. This is the removal 775 time, Trem and is given by: 777 Trem = Tret + Iret 779 where, as before, Iret is the retire interval. This will be zero 780 unless [RFC5011] is being followed, in which case Iret will be equal 781 to the RFC5011 remove hold-down time value of 30 days. 783 Notes: 785 1. In the case of a ZSK, as pre-publication is the method of choice, 786 only one key at a time is used to sign the zone. Therefore, when 787 the active ZSK is retired, there may be copies of signatures 788 created using it in the caches of downstream validators. For 789 this reason, a copy of the ZSK has to be kept in the zone until 790 all cached signatures have expired. 792 With a KSK - where double RRset is the method of choice - both 793 the active key and the successor key sign the DNSKEY RRset. By 794 the time the successor becomes active, any validator with the 795 DNSKEY RRset in its cache has a copy of the successor key. 796 Therefore as soon as the active key is retired, it can be removed 797 from the zone - there is no retire interval (unless [RFC5011] is 798 being followed) or dead time (although for completeness, and in 799 analogy with the ZSK, a dead time could be defined by Tdea = 800 Trem). 802 2. There is an additional consideration when introducing a KSK into 803 a zone for the first time, and that is that no validator can be 804 in a position where it can access the trust anchor before the KSK 805 appears in the zone. To do so will cause the validator to 806 declare the zone to be bogus. 808 The second point is important: in the case of a secure parent, it 809 means ensuring that the DS record is not published in the parent zone 810 until there is no possibility that a validator can obtain the record 811 yet not be able to obtain the corresponding DNSKEY. In the case of 812 an insecure parent, i.e. the initial creation of a new security apex, 813 it is important to not configure trust anchors in validators until 814 the DNSKEY RRset has had sufficient time to propagate. In both 815 cases, this time is the trust anchor availability time (Ttaa) given 816 by: 818 Ttaa >= Tpub + IpubC 820 where 821 IpubC = DprpC + TTLkeyC 823 or 825 IpubC = DprpC + IngcC 827 The first expression applies if there was previously a DNSKEY RRset 828 in the child zone, the expression for IpubC including the TTLkeyC 829 term to account for the time taken for that RRset to expire from 830 caches. If the introduction of the KSK caused the appearance of the 831 first DNSKEY RRset in the child zone, the second expression applies 832 in which the TTLkeyC term is replaced by one to allow for the effect 833 of negative caching. 835 4.5. Key States 837 The key states for a KSK during the rollover are identical to those 838 in Figure 2. 840 4.6. Stand-By Key-Signing Keys 842 In the same way that additional ZSKs are kept in a ready state in the 843 zone to act as emergency keys, additional KSKs need to be available 844 in the ready state for the same reason. The number of stand-by keys 845 kept available is a matter of key management policy, and the logic 846 for the introduction of stand-by keys into the zone follows the same 847 reasoning as that given in Section 3.3 on the introduction of 848 stand-by ZSKs. 850 5. Algorithm Considerations 852 The preceding sections have implicitly assumed that all keys and 853 signatures are created using a single algorithm. However, [RFC4035] 854 (section 2.4) states that "There MUST be an RRSIG for each RRset 855 using at least one DNSKEY of each algorithm in the zone apex DNSKEY 856 RRset". 858 Except in the case of an algorithm rollover - where the algorithms 859 used to create the signatures are being changes - there is no 860 relationship between the keys of different algorithms. This means 861 that they can be rolled independently of one another. (Indeed, the 862 keys for each algorithm could, if desired, have different TTLs.) In 863 other words, the key rollover logic described above should be run 864 separately for each algorithm; the union of the results is included 865 in the zone, which is signed using the active key for each algorithm. 867 6. Summary 869 For ZSKs, "pre-publication" is generally considered to be the 870 preferred way of rolling keys. As shown in this document, the time 871 taken to roll is wholly dependent on parameters under the control of 872 the zone manager. 874 In contrast, "double RRset" is the most efficient method for KSK 875 rollover due to the ability to have new DS records and DNSKEY RRsets 876 propagate in parallel. The time taken to roll KSKs may depend on 877 factors related to the parent zone if the parent is signed. For 878 zones that intend to comply with the recommendations of [RFC5011], in 879 virtually all cases the rollover time will be determined by the 880 RFC5011 add and remove hold-down times. It should be emphasised that 881 this delay is a policy choice and not a function of timing values and 882 that it also requires changes to the rollover process due to the need 883 to manage revocation of trust anchors. 885 Finally, the treatment of emergency rollover is significantly 886 simplified by the introduction of stand-by keys as standard practice 887 during all types of rollovers. 889 7. IANA Considerations 891 This memo includes no request to IANA. 893 8. Security Considerations 895 This document does not introduce any new security issues beyond those 896 already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. 898 9. Acknowledgements 900 The authors gratefully acknowledge help and contributions from Roy 901 Arends and Wouter Wijngaards. 903 10. Change History 905 o draft-morris-dnsop-dnssec-key-timing-01 906 * Use latest boilerplate for IPR text. 907 * List different ways to roll a KSK (acknowledgements to Mark 908 Andrews). 909 * Restucture to concentrate on key timing, not management 910 procedures. 912 * Change symbol notation (Diane Davidowicz and others). 913 * Added key state transition diagram (Diane Davidowicz). 914 * Corrected spelling, formatting, grammatical and style errors 915 (Diane Davidowicz, Alfred Hones and Jinmei Tatuya). 916 * Added note that in the case of multiple algorithms, the 917 signatures and rollovers for each algorithm can be considered as 918 more or less independent (Alfred Hones). 919 * Take account of the fact that signing a zone is not atomic 920 (Chris Thompson). 921 * Add section contrasting pre-publication rollover with double- 922 signature rollover (Matthijs Mekking). 923 * Retained distinction between first and subsequent keys in 924 definition of initial publication interval (Matthijs Mekking). 926 o draft-morris-dnsop-dnssec-key-timing-00 927 Initial draft. 929 11. Normative References 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 932 Requirement Levels", BCP 14, RFC 2119, March 1997. 934 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 935 NCACHE)", RFC 2308, March 1998. 937 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 938 Rose, "DNS Security Introduction and Requirements", 939 RFC 4033, March 2005. 941 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 942 Rose, "Resource Records for the DNS Security Extensions", 943 RFC 4034, March 2005. 945 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 946 Rose, "Protocol Modifications for the DNS Security 947 Extensions", RFC 4035, March 2005. 949 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 950 Trust Anchors", RFC 5011, September 2007. 952 Appendix A. List of Symbols 954 The document defines a number of symbols, all of which are listed 955 here. All are of the form: 957 All symbols used in the text are of the form: 959 961 where: 963 is an upper-case character indicating what type the symbol is. 964 Defined types are: 966 D delay: interval that is a feature of the process 968 L lifetime: calculated interval set by the zone manager 970 I interval between two events 972 L lifetime: interval set by the zone manager 974 SOA parameter related to SOA RR 976 T a point in time 978 TTL TTL of a record 980 T and I are self-explanatory. D, and L are also time periods, but 981 whereas I values are intervals between two events (even if the events 982 are defined in terms of the interval, e.g. the dead time occurs 983 "retire interval" after the retire time), D, and L are fixed 984 intervals. An "L" interval (lifetime) is chosen by the zone manager 985 and is a feature of policy. A "D" interval (delay) is a feature of 986 the process, probably outside control of the zone manager. SOA and 987 TTL are used just because they are common terms terms. 989 is lower-case and defines what object or event the variable is 990 related to, e.g. 992 act active 994 ngc negative cache 996 pub publication 998 Finally, is a capital letter that distinguishes between the 999 same variable applying to different instances of an object and is one 1000 of: 1002 C child 1003 P parent 1005 S successor 1007 The list of variables used in the text is: 1009 Dprp Propagation delay. The amount of time for a change made at 1010 a master nameserver to propagate to all the slave 1011 nameservers. 1013 DprpP Propagation delay in the parent zone. 1015 Dreg Registration delay. As a parent zone are often managed by 1016 a different organisation to the one under consideration, 1017 the delays associated with passing data between zones is 1018 captured by this term. 1020 Dskw Clock skew. The maximum difference in time between the 1021 signing system and the resolver. 1023 Dsgn Signing delay. After the introduction of a new ZSK, the 1024 amount of time taken for all the RRs in the zone to be 1025 signed with it. 1027 Ingc Negative cache interval. 1029 Ipub Publication interval. The amount of time that must elapse 1030 after the publication of a key before it can be considered 1031 to have entered the ready state. 1033 IpubC Publication interval in the child zone. 1035 IpubP Publication interval in the parent zone. 1037 Iret Retire interval. The amount of time that must elapse after 1038 a key enters the retire state for any signatures created 1039 with it to be purged from validator caches. 1041 Lksk Lifetime of a key-signing key. This is the intended amount 1042 of time for which this particular KSK is regarded as the 1043 active KSK. Depending on when the key is rolled-over, the 1044 actual lifetime may be longer or shorter than this. 1046 Lzsk Lifetime of a zone-signing key. This is the intended 1047 amount of time for which the ZSK is used to sign the zone. 1048 Depending on when the key is rolled-over, the actual 1049 lifetime may be longer or shorter than this. 1051 Lsig Lifetime of a signature: the difference in time between the 1052 signature's expiration time and the time at which the 1053 signature was created. (Note that this is not the 1054 difference between the signature's expiration and inception 1055 times: the latter is usually set a small amount of time 1056 before the signature is created to allow for clock skew 1057 between the signing system and the validator.) 1059 SOAmin Value of the "minimum" field from an SOA record. 1061 Tact Active time of the key. For a ZSK, the time that they key 1062 is first used to sign the zone. For a KSK, the time at 1063 which this key is regarded as being the principal KSK for 1064 the zone. 1066 Tdea Dead time of a key. Applicable only to ZSKs, this is the 1067 time at which any record signatures held in validator 1068 caches are guaranteed to be created with the successor key. 1070 Tgen Generate time of a key. The time that a key is created. 1072 Tpub Publish time of a key. The time that a key appears in a 1073 zone for the first time. 1075 TpubS Publish time of the successor key. 1077 Trem Removal time of a key. The time at which a key is removed 1078 from the zone. 1080 Tret Retire time of a key. The time at which a successor key 1081 starts being used to sign the zone. 1083 Trdy Ready time of a key. The time at which it can be 1084 guaranteed that a validators that have key information from 1085 this zone cached have a copy of this key in their cache. 1086 (In the case of KSKs, should the validators also have DS 1087 information from the parent zone cached, the cache must 1088 include information about the DS record corresponding to 1089 the key.) 1091 TrdyS Ready time of a successor key. 1093 TTLds Time to live of a DS record (in the parent zone). 1095 TTLkey Time to live of a DNSKEY record. 1097 TTLkeyC Time to live of a DNSKEY record in the child zone. 1099 TTLsoa Time to live of a SOA record. 1101 TTLsig Time to live of an RRSIG record. 1103 Ttsa Trust anchor availability time. The time at which a trust 1104 anchor record can be made available when a KSK is first 1105 introduced into a zone. 1107 Authors' Addresses 1109 Stephen Morris 1110 Nominet 1111 Minerva House, Edmund Halley Road 1112 Oxford, OX4 4DQ 1113 UK 1115 Phone: +44 1865 332211 1116 Email: stephen@nominet.org.uk 1118 Johan Ihren 1119 Autonomica 1120 Franzengatan 5 1121 Stockholm, SE-112 51 1122 Sweden 1124 Phone: +46 8615 8573 1125 Email: johani@autonomica.se 1127 John Dickinson 1128 Stables 4 Suite 10, Howbery Park 1129 Wallingford, OX10 8BA 1130 UK 1132 Phone: 1133 Email: jad@jadickinson.co.uk