idnits 2.17.1 draft-ietf-dnsop-dnssec-key-timing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1254: '...ates that "There MUST be an RRSIG for ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2010) is 5049 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Morris 3 Internet-Draft ISC 4 Intended status: Informational J. Ihren 5 Expires: January 2, 2011 Netnod 6 J. Dickinson 7 Sinodun 8 July 1, 2010 10 DNSSEC Key Timing Considerations 11 draft-ietf-dnsop-dnssec-key-timing-00.txt 13 Abstract 15 This document describes the issues surrounding the timing of events 16 in the rolling of a key in a DNSSEC-secured zone. It presents 17 timelines for the key rollover and explicitly identifies the 18 relationships between the various parameters affecting the process. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 2, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 56 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 65 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 66 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 13 67 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 14 68 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17 69 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 17 70 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 20 71 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 22 72 3.3.4. Interaction with Configured Trust Anchors . . . . . . 25 73 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 25 74 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 25 75 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 26 76 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27 77 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28 78 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 82 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 86 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 30 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 89 1. Introduction 91 1.1. Key Rolling Considerations 93 When a zone is secured with DNSSEC, the zone manager must be prepared 94 to replace ("roll") the keys used in the signing process. The 95 rolling of keys may be caused by compromise of one or more of the 96 existing keys, or it may be due to a management policy that demands 97 periodic key replacement for security or operational reasons. In 98 order to implement a key rollover, the keys need to be introduced 99 into and removed from the zone at the appropriate times. 100 Considerations that must be taken into account are: 102 o DNSKEY records and associated information (such as RRSIG records 103 created with the key or the associated DS records) are not only 104 held at the authoritative nameserver, they are also cached at 105 client resolvers. The data on these systems can be interlinked, 106 e.g. a validating resolver may try to validate a signature 107 retrieved from a cache with a key obtained separately. 109 o A query for the key RRset returns all DNSKEY records in the zone. 110 As there is limited space in the UDP packet (even with EDNS0 111 support), dead key records must be periodically removed. (For the 112 same reason, the number of stand-by keys in the zone should be 113 restricted to the minimum required to support the key management 114 policy.) 116 o Zone "boot-strapping" events, where a zone is signed for the first 117 time, can be common in configurations where a large number of 118 zones are being served. Procedures should be able to cope with 119 the introduction of keys into the zone for the first time as well 120 as "steady-state", where the records are being replaced as part of 121 normal zone maintenance. 123 o To allow for an emergency re-signing of the zone as soon as 124 possible after a key compromise has been detected, stand-by keys 125 (additional keys over and above those used to sign the zone) need 126 to be present. 128 Management policy, e.g. how long a key is used for, also needs to be 129 considered. However, the point of key management logic is not to 130 ensure that a "rollover" is completed at a certain time but rather to 131 ensure that no changes are made to the state of keys published in the 132 zone until it is "safe" to do so ("safe" in this context meaning that 133 at no time during the rollover process does any part of the zone ever 134 go bogus). In other words, although key management logic enforces 135 policy, it may not enforce it strictly. 137 1.2. Types of Keys 139 Although DNSSEC validation treats all keys equally, [RFC4033] 140 recognises the broad classification of zone-signing keys (ZSK) and 141 key-signing keys (KSK). A ZSK is used to authenticate information 142 within the zone; a KSK is used to authenticate the key set in the 143 zone. The main implication for this distinction concerns the 144 consistency of information during a rollover. 146 During operation, a validating resolver must use separate pieces of 147 information to perform an authentication. At the time of 148 authentication, each piece of information may be in the validating 149 resolver's cache or may need to be retrieved from the authoritative 150 server. The rollover process needs to happen in such a way that at 151 all times through the rollover the information is consistent. With a 152 ZSK, the information is the RRSIG (plus associated RRset) and the 153 DNSKEY. These are both obtained from the same zone. In the case of 154 the KSK, the information is the DNSKEY and DS RRset with the latter 155 being obtained from a different zone. 157 There are similarities in the rolling of ZSKs and KSKs: replace the 158 RRSIG (plus RR) by the DNSKEY and replace the DNSKEY by the DS, and 159 the ZSK rolling algorithms are virtually the same as the KSK 160 algorithms. However, there are a number of differences, and for this 161 reason the two types of rollovers are described separately in this 162 document. 164 1.3. Terminology 166 The terminology used in this document is as defined in [RFC4033] and 167 [RFC5011]. 169 A large number of symbols are used to identify times, intervals, etc. 170 All are listed in Appendix A. 172 2. Rollover Methods 174 2.1. ZSK Rollovers 176 A ZSK can be rolled in one of three ways: 178 o Pre-Publication. Described in [RFC4641], the new key is 179 introduced into the DNSKEY RRset, leaving the existing keys and 180 signatures in place. This state of affairs remains in place for 181 long enough to ensure that any DNSKEY RRsets cached in client 182 validating resolvers contain both keys. At that point signatures 183 created with the old key can be replaced by those created with the 184 new key, and the old signatures removed. During the re-signing 185 process (which may or may not be atomic depending on how the zone 186 is managed), it doesn't matter which key an RRSIG record retrieved 187 by a client was created with; clients with a cached copy of the 188 DNSKEY RRset will have a copy containing both the old and new 189 keys. 191 Once the zone contains only signatures created with the new key, 192 there is an interval during which RRSIG records created with the 193 old key expire from client caches. After this, there will be no 194 signatures anywhere that were created using the old key, and it 195 can can be removed from the DNSKEY RRset. 197 o Double-Signature. Also mentioned in [RFC4641], this involves 198 introducing the new key into the zone and using it to create 199 additional RRSIG records; the old key and existing RRSIG records 200 are retained. During the period in which the zone is being signed 201 (again, the signing process may not be atomic), client resolvers 202 are always able to validate RRSIGs: any combination of old and new 203 DNSKEY RRset and RRSIG allows at least one signature to be 204 validated. 206 Once the signing process is complete and enough time has elapsed 207 to allow all old information to expire from caches, the old key 208 and signatures can be removed from the zone. As before, during 209 this period any combination of DNSKEY RRset and RRSIG will allow 210 validation of at least one signature. 212 o Double-RRSIG. Strictly speaking, the use of the term "Double- 213 Signature" above is a misnomer as the method is not only double 214 signature, it is also double key as well. A true Double-Signature 215 method (here called the Double-RRSIG method) involves introducing 216 new signatures in the zone (while still retaining the old ones) 217 but not the new key. 219 Once the signing process is complete and enough time has elapsed 220 to ensure that all caches that may contain an RR and associated 221 RRSIG to have a copy of both signatures, the ZSK is changed. 222 After a further interval during which the old DNSKEY RRset expires 223 from caches, the old signatures are removed from the zone. 225 Of three methods, Double-Signature is the simplest conceptually - 226 introduce the new key and new signatures, then approximately one TTL 227 later remove the old key and signatures. The drawback of this method 228 is a noticeable increase in the size of the DNSSEC data, affecting 229 both the overall size of the zone and the size of the responses. 231 Pre-Publication is more complex - introduce the new key, 232 approximately one TTL later sign the records, and approximately one 233 TTL after that remove the old key. However, the amount of DNSSEC 234 data is kept to a minimum which reduces the impact on performance. 236 The Double-RRSIG combines the increase in data volume of the Double- 237 Signature method with the complexity of Pre-Publication. It has few 238 (if any) advantages and a description is only included here for 239 completeness. 241 2.2. KSK Rollovers 243 In the ZSK case the issue for the validating resolver is to ensure 244 that it has access to the ZSK that corresponds to a particular 245 signature. In the KSK case this can never be a problem as the KSK is 246 only used for one signature (that over the DNSKEY RRset) and both the 247 key the signature travel together. Instead, the issue is to ensure 248 that the KSK is trusted. 250 Trust in the KSK is either due to the existence of an explicitly 251 configured trust anchor in the validating resolver or DS record in 252 the parent zone (which is itself trusted). If the former, [RFC5011] 253 timings will be needed to roll the keys. If the latter, the rollover 254 algorithm will need to involve the parent zone in the addition and 255 removal of DS records, so timings are not wholly under the control of 256 the zone manager. (The zone manager may elect to include [RFC5011] 257 timings in the key rolling process so as to cope with the possibility 258 that the key has also been explicitly configured as a trust anchor.) 260 It is important to note that this does not preclude the development 261 of key rollover logic; in accordance with the goal of the rollover 262 logic being able to determine when a state change is "safe", the only 263 effect of being dependent on the parent is that there may be a period 264 of waiting for the parent to respond in addition to any delay the key 265 rollover logic requires. Although this introduces additional delays, 266 even with a parent that is less than ideally responsive the only 267 effect will be a slowdown in the rollover state transitions. This 268 may cause a policy violation, but will not cause any operational 269 problems. 271 Like the ZSK case, there are three methods for rolling a KSK: 273 o Double-Signature: Also known as Double-DNSKEY, the new KSK is 274 added to the DNSKEY RRset which is then signed with both the old 275 and new key. After waiting for the old RRset to expire from 276 caches, the DS record in the parent zone is changed. After 277 waiting a further interval for this change to be reflected in 278 caches, the old key is removed from the RRset. (The name "Double- 279 Signature" is used because, like the ZSK method of the same name, 280 the new key is introduced and immediately used for signing.) 282 o Double-DS: the new DS record is published. After waiting for this 283 change to propagate into the caches of all validating resolvers, 284 the KSK is changed. After a further interval during which the old 285 DNSKEY RRset expires from caches, the old DS record is removed. 287 o Double-RRset: the new KSK is added to the DNSKEY RRset which is 288 then signed with both the old and new key, and the new DS record 289 added to the parent zone. After waiting a suitable interval for 290 the old DS and DNSKEY RRsets to expire from validating resolver 291 caches, the old DNSKEY and DS record are removed. 293 In essence, "Double-Signature" means that the new KSK is introduced 294 first and used to sign the DNSKEY RRset. The DS record is changed, 295 and finally the old KSK removed. With "Double-DS" it is the other 296 way around. Finally, Double-RRset does both updates more or less in 297 parallel. 299 The strategies have different advantages and disadvantages: 301 o Double-Signature minimizes the number of interactions with the 302 parent zone. However, for the period of the rollover the DNSKEY 303 RRset is signed with two KSKs, so increasing the size of the 304 response to a query for this data. 306 o Double-DS keeps the size of the DNSKEY RRset to a minimum, but 307 does require the additional administrative overhead of two 308 interactions with the parent to roll a KSK. (Although this can be 309 mitigated if the parent has the ability for a child zone to 310 schedule the withdrawal of the old key at the same time as the 311 introduction of the new one.) 313 o Finally, Double-RRset allows the rollover to be done in roughly 314 half the time of the other two methods; it also supports policies 315 that require a period of running with old and new KSKs 316 simultaneously. However, it does have the disadvantages of both 317 the other two methods - it requires two signatures during the 318 period of the rollover and two interactions with the parent. 320 2.3. Summary 322 The methods can be summarised as follows: 324 +------------------+------------------+-----------------------------+ 325 | ZSK Method | KSK Method | Description | 326 +------------------+------------------+-----------------------------+ 327 | Pre-Publication | (not applicable) | Publish the DNSKEY before | 328 | | | the RRSIG. | 329 | Double-Signature | Double-Signature | Publish the DNSKEY and | 330 | | | RRSIG at same time. (For a | 331 | | | KSK, this happens before | 332 | | | the DS is published.) | 333 | Double-RRSIG | (not applicable) | Publish RRSIG before the | 334 | | | DNSKEY. | 335 | (not applicable) | Double-DS | Publish DS before the | 336 | | | DNSKEY. | 337 | (not applicable) | Double-RRset | Publish DNSKEY and DS in | 338 | | | parallel. | 339 +------------------+------------------+-----------------------------+ 341 Table 1 343 3. Key Rollover Timelines 345 3.1. Key States 347 During the rolling process, a key moves through different states. 348 These states are: 350 Generated The key has been created, but has not yet been used for 351 anything. 353 Published The DNSKEY record - or information associated with it - 354 is published in the zone, but predecessors of the key (or 355 associated information) may be held in resolver caches. 357 The idea of "associated information" is used in rollover 358 methods where RRSIG or DS records are published first and 359 the DNSKEY is changed in an atomic operation. It allows 360 the rollover still to be thought of as moving through a 361 set of states. In the rest of this section, the term 362 "key" should be taken to mean "key or associated 363 information". 365 Ready The key has been published for long enough to guarantee 366 that all caches that might contain a copy of the key 367 RRset have a copy that includes this key. 369 Active The key is in the zone and has started to be used to sign 370 RRsets or authenticate the DNSKEY RRset. Note that when 371 this state is entered, it might not be possible for every 372 validating resolver to use the key for validation: the 373 zone signing may not have finished, or the data might not 374 have reached the resolver because of propagation delays 375 and/or caching issues. If this is the case, the resolver 376 will have to rely on the key's predecessor instead. 378 Retired The key is in the zone but a successor key has become 379 active. As there may still be information in caches that 380 that require use of the key, it is being retained until 381 this information expires. 383 Dead The key is published in the zone but there is no 384 information anywhere that requires its presence. 386 Removed The key has been removed from the zone. 388 There is one additional state, used where [RFC5011] considerations 389 are in effect (see Section 3.3.4): 391 Revoked The key is published for a period with the "revoke" bit 392 set as a way of notifying validating resolvers that have 393 configured it as a trust anchor that it is about to be 394 removed from the zone. 396 3.2. Zone-Signing Key Timelines 398 3.2.1. Pre-Publication Method 400 The following diagram shows the time line of a particular ZSK and its 401 replacement by its successor using the Pre-Publication method. Time 402 increases along the horizontal scale from left to right and the 403 vertical lines indicate events in the life of the key. The events 404 are numbered; significant times and time intervals are marked. 406 |1| |2| |3| |4| |5| |6| |7| |8| |9| 407 | | | | | | | | | 408 Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| 409 | | | | | | | | | 410 Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - 411 | | | | | | | | | 412 Tgen Tpub Trdy Tact TpubS Tret Tdea Trem 414 ---- Time ----> 416 Figure 1: Timeline for a Pre-Publication ZSK rollover. 418 Event 1: key N is generated at the generate time (Tgen). Although 419 there is no reason why the key cannot be generated immediately prior 420 to publication in the zone (Event 2), some implementations may find 421 it convenient to create a pool of keys in one operation and draw from 422 that pool as required. For this reason, it is shown as a separate 423 event. Keys that are available for use but not published are said to 424 be generated. 426 Event 2: key N's DNSKEY record is put into the zone, i.e. it is added 427 to the DNSKEY RRset which is then re-signed with the current key- 428 signing key. The time at which this occurs is the key's publication 429 time (Tpub), and the key is now said to be published. Note that the 430 key is not yet used to sign records. 432 Event 3: before it can be used, the key must be published for long 433 enough to guarantee that any resolver that has a copy of the DNSKEY 434 RRset from the zone in its cache will have a copy of the RRset that 435 includes this key: in other words, that any prior cached information 436 about the DNSKEY RRset has expired. 438 This interval is the publication interval (Ipub) and, for the second 439 or subsequent keys in the zone, is given by: 441 Ipub = Dprp + TTLkey 443 Here, Dprp is the propagation delay - the time taken for any change 444 introduced at the master to replicate to all slave servers - which 445 depends on the depth of the master-slave hierarchy. TTLkey is the 446 time-to-live (TTL) for the DNSKEY records in the zone. The sum is 447 therefore the time taken for existing DNSKEY records to expire from 448 the caches of downstream validating resolvers, regardless of the 449 nameserver from which they were retrieved. 451 In the case of the first key in the zone, Ipub is slightly different 452 because it is not information about a DNSKEY RRset that may be 453 cached, it is information about its absence. In this case: 455 Ipub = Dprp + Ingc 457 where Ingc is the negative cache interval from the zone's SOA record, 458 calculated according to [RFC2308] as the minimum of the TTL of the 459 SOA record itself (TTLsoa), and the "minimum" field in the record's 460 parameters (SOAmin), i.e. 462 Ingc = min(TTLsoa, SOAmin) 464 After a delay of Ipub, the key is said to be ready and could be used 465 to sign records. The time at which this event occurs is the key's 466 ready time (Trdy), which is given by: 468 Trdy = Tpub + Ipub 470 Event 4: at some later time, the key starts being used to sign 471 RRsets. This point is the active time (Tact) and after this, the key 472 is said to be active. 474 Event 5: while this key is active, thought must be given to its 475 successor (key N+1). As with the introduction of the currently 476 active key into the zone, the successor key will need to be published 477 at least Ipub before it is used. Denoting the publication time of 478 the successor key by TpubS, then: 480 TpubS <= Tact + Lzsk - Ipub 482 Here, Lzsk is the length of time for which a ZSK will be used (the 483 ZSK lifetime). It should be noted that unlike the publication 484 interval, Lzsk is not determined by timing logic, but by key 485 management policy. Lzsk will be set by the operator according to 486 their assessment of the risks posed by continuing to use a key and 487 the risks associated with key rollover. However, operational 488 considerations may mean a key is active for slightly more or less 489 than Lzsk. 491 Event 6: while the key N is still active, its successor becomes 492 ready. From this time onwards, it could be used to sign the zone. 494 Event 7: at some point the decision is made to start signing the zone 495 using the successor key. This will be when the current key has been 496 in use for an interval equal to the ZSK lifetime, hence: 498 Tret = Tact + Lzsk 500 This point in time is the retire time (Tret) of key N; after this the 501 key is said to be retired. (This time is also the point at which the 502 successor key becomes active.) 504 Event 8: the retired key needs to be retained in the zone whilst any 505 RRSIG records created using this key are still published in the zone 506 or held in resolver caches. (It is possible that a resolver could 507 have an unexpired RRSIG record and an expired DNSKEY RRset in the 508 cache when it is asked to provide both to a client. In this case the 509 DNSKEY RRset would need to be looked up again.) This means that once 510 the key is no longer used to sign records, it should be retained in 511 the zone for at least the retire interval (Iret) given by: 513 Iret = Dsgn + Dprp + TTLsig 515 Dsgn is the delay needed to ensure that all existing RRsets have been 516 re-signed with the new key. Dprp is (as described above) the 517 propagation delay, required to guarantee that the updated zone 518 information has reached all slave servers, and TTLsig is the TTL of 519 the RRSIG records. 521 (It should be noted that an upper limit on the retire interval is 522 given by: 524 Iret = Lsig + Dskw 526 where Lsig is the lifetime of a signature (i.e. the interval between 527 the time the signature was created and the signature end time), and 528 Dskw is the clock skew - the maximum difference in time between the 529 server and a validating resolver. The reasoning here is that 530 whatever happens, a key only has to be available while any signatures 531 created with it are valid. Wherever a signature record is held - 532 published in the zone and/or held in a resolver cache - it won't be 533 valid for longer than Lsig after it was created. The Dskw term is 534 present to account for the fact that the signature end time is an 535 absolute time rather than interval, and systems may not agree exactly 536 about the time.) 538 The time at which all RRSIG records created with this key have 539 expired from resolver caches is the dead time (Tdea), given by: 541 Tdea = Tret + Iret 543 ...at which point the key is said to be dead. 545 Event 9: at any time after the key becomes dead, it can be removed 546 from the zone and the DNSKEY RRset re-signed with the current key- 547 signing key. This time is the removal time (Trem), given by: 549 Trem >= Tdea 551 ...at which time the key is said to be removed. 553 3.2.2. Double-Signature Method 555 In the Double-Signature method, both the new key and signatures 556 created using it are introduced at the same time. After a period 557 during which this information propagates to validating resolver 558 caches, the old key and signature are removed. The time line for the 559 method is shown below: 561 |1| |2| |3| |4| |5| |6| 562 | | | | | | 563 Key N | |<-------Lzsk------>|<-----Iret----->| | 564 | | | | | | 565 Key N+1 | | | |<----------Lzsk------- - - 566 | | | | | | 567 Tgen Tact Tret Tdea Trem 569 ---- Time ----> 571 Figure 2: Timeline for a Double-Signature ZSK rollover. 573 Event 1: key N is generated at the generate time (Tgen). Although 574 there is no reason why the key cannot be generated immediately prior 575 to publication in the zone (Event 2), some implementations may find 576 it convenient to create a pool of keys in one operation and draw from 577 that pool as required. For this reason, it is shown as a separate 578 event. Keys that are available for use but not published are said to 579 be generated. 581 Event 2: key N is added to the DNSKEY RRset and is immediately used 582 to sign the zone; existing signatures in the zone are not removed. 583 This is the active time (Tact) and the key is said to be active. 585 Event 3: at some time later, the predecessor key (key N-1) and its 586 signatures can be withdrawn from the zone. (The timing of key 587 removal is discussed further in the description of event 5.) 589 Event 4: the successor key (key N+1) is introduced into the zone and 590 starts being used to sign RRsets. The successor is key is now active 591 and the current key (key N) is said to be retired. This time is the 592 retire time of the key (Tret); it is also the active time of the 593 successor key (TactS). 595 Tret = Tact + Lzsk 597 Event 5: before key N can be withdrawn from the zone, all RRsets that 598 need to be signed must have been signed by the successor key (as a 599 result, all these RRsets are now signed twice, once by key N and once 600 by its successor) and the information must have reached all 601 validating resolvers that may have RRsets from this zone cached. 603 This takes Iret, the retire interval, given by the expression: 605 Iret = Dsgn + Dprp + max(TTLkey, TTLsig) 607 As before, Dsgn is the time taken to sign the zone with the new key 608 and Dprp is the propagation delay. The final term is the period to 609 wait for old key and signature data to expire from caches. After the 610 end of this interval, key N is said to be dead. This occurs at the 611 dead time (Tdea) so: 613 Tdea = Tret + Iret 615 Event 6: at some later time key N and its signatures can be removed 616 from the zone. This is the removal time Trem, given by: 618 Trem >= Tdea 620 3.2.3. Double-RRSIG Method 622 As noted above, "Double-Signature" is simultaneous rollover of both 623 signature and key. The time line for a pure Double-Signature ZSK 624 rollover (the Double-RRSIG method) - where new signatures are 625 introduced, the key changed, and finally the old signatures removed - 626 is shown below: 628 |1||2| |3| |4||5| |6||7| |8||9| |10| |11| 629 | | | | | | | | | | | 630 Key N | |<-Dsgn->| | |<-----------Lzsk-------->|<-Iret->| | 631 | |<---IpubG-->| |<-IpubK->| | | | | | 632 | | | | | | | | | | | 633 Key N+1 | | | | | | |<-IpubG->| | | | 634 | | | | | | | | | | | 635 Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem 637 ---- Time ----> 639 Figure 3: Timeline for a Double-Signature ZSK rollover. 641 Event 1: key N is generated at the generate time (Tgen). Although 642 there is no reason why the key cannot be generated immediately prior 643 to publication in the zone (Event 2), some implementations may find 644 it convenient to create a pool of keys in one operation and draw from 645 that pool as required. For this reason, it is shown as a separate 646 event. Keys that are available for use but not published are said to 647 be generated. 649 Event 2: key N is used to sign the zone but existing signatures are 650 retained. Although the new ZSK is not published in the zone at this 651 point, for analogy with the other ZSK rollover methods and because 652 this is the first time that key information is visible (albeit 653 indirectly through the created signatures) this time is called the 654 publish time (Tpub). 656 Event 3: after the signing interval, Dsgn, all RRsets that need to be 657 signed have been signed by the new key. (As a result, all these 658 RRsets are now signed twice, once by the existing key and once by the 659 (still-absent) key N. 661 Event 4: there is now a delay while the this information reaches all 662 validating resolvers that may have RRsets from the zone cached. This 663 interval is given by the expression: 665 Dprp + TTLsig 667 ...comprising the delay for the information to propagate through the 668 nameserver infrastructure plus the time taken for signature 669 information to expire from caches. 671 Again in analogy with other key rollover methods, this is defined as 672 key N's ready time (Trdy) and the key is said to be in the ready 673 state. (Although the key is not in the zone, it is ready to be 674 used.) The interval between the publication and ready times is the 675 publication interval of the signature, IpubG, i.e. 677 Trdy = Tpub + IpubG 679 where 681 IpubG = Dsgn + Dprp + TTLsig 683 Event 5: at some later time the predecessor key is removed and the 684 key N added to the DNSKEY RRset. As all the RRs have signatures 685 created by the old and new keys, the records can still be 686 authenticated. This time is the active time (Tact) and the key is 687 now said to be active. 689 Event 6: After IpubK - the publication interval of the key - the 690 newly added DNSKEY RRset has propagated through to all validating 691 resolvers. At this point the old signatures can be removed from the 692 zone. IpubK is given by: 694 IpubK = Dprp + TTLkey 696 Event 7: as before, at some later time thought must be given to 697 rolling the key. The first step is to publish signatures created by 698 the successor key (key N+1) early enough so that key N can be 699 replaced after it has been active for its scheduled lifetime. This 700 occurs at TpubS (the publication time of the successor), given by: 702 TpubS <= Tact + Lzsk - IpubG 704 Event 8: the signatures have propagated through the zone and the new 705 key could be added to the zone. This time is the ready time of the 706 successor (TrdyS). 708 TrdyS = TpubS + IpubG 710 ... where IpubG is as defined above. 712 Event 9: at some later time key N is removed from the zone and the 713 successor key added. This is the retire time of the key (Tret). 715 Event 10: The signatures must remain in the zone for long enough that 716 the new DNSKEY RRset has had enough time to propagate to all caches. 717 Once caches contain the new DNSKEY, the old signatures are no longer 718 of use and can be considered to be dead. The time at which this 719 occurs is the dead time (Tdea), given by: 721 Tdea = Tret + Iret 723 ... where Iret is the retire interval, given by: 725 Iret = IpubK 727 Event 11: At some later time the signatures can be removed from the 728 zone. Although the key has is not longer in the zone, this is 729 information associated with it and so the time can be regarded as the 730 key's remove time (Trem), given by: 732 Trem >= Tdea 734 3.3. Key-Signing Key Rollover Timelines 736 3.3.1. Double-Signature Method 738 The Double-Signature method (also knows as the double-DNSKEY method) 739 involves introducing the new KSK to the zone and waiting until its 740 presence has been registered by all validating resolvers. At this 741 point, the DS record in the parent is changed. Once that change has 742 propagated to all validating resolvers, the old KSK is removed. 744 The timing diagram for such a rollover is: 746 |1| |2| |3| |4| |5| |6| 747 | | | | | | 748 Key N | |<-Ipub->|<--->|<-Dreg->|<---------Lksk--- - - 749 | | | | | | 750 Key N+1 | | | | | | 751 | | | | | | 752 Tgen Tpub Trdy Tsub Tact 754 ---- Time ----> 756 (continued...) 758 |7| |8| |9| |10| |11| |12| 759 | | | | | | 760 Key N - - -------------Lksk------->|<-Iret->| | 761 | | | | | | 762 Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - 763 | | | | | | 764 TpubS TrdyS TsubS Tret Tdea Trem 766 ---- Time (cont) ----> 768 Figure 4: Timeline for a Double-Signature KSK rollover. 770 Event 1: key N is generated at time Tgen. As before, although there 771 is no reason why the key cannot be generated immediately prior to 772 publication, some implementations may find it convenient to create a 773 central pool of keys and draw from it. For this reason, it is again 774 shown as a separate event. 776 Event 2: key N is introduced into the zone; it is added to the DNSKEY 777 RRset, which is then signed by key N and all currently active KSKs. 778 (So at this point, the DNSKEY RRset is signed by both key N and its 779 predecessor KSK. If other KSKs were active, it is signed by these as 780 well.) This is the publication time (Tpub); after this the key is 781 said to be published. 783 Event 3: before it can be used, the key must be published for long 784 enough to guarantee that any validating resolver that has a copy of 785 the DNSKEY RRset from the zone in its cache will have a copy of the 786 RRset that includes this key: in other words, that any prior cached 787 information about the DNSKEY RRset has expired. 789 The interval is the publication interval (Ipub) and, for the second 790 or subsequent KSKs in the zone, is given by: 792 Ipub = Dprp + TTLkey 794 ... where Dprp is the propagation delay for the zone and TTLkey the 795 TTL for the DNSKEY RRset. The time at which this occurs is the key's 796 ready time, Trdy, given by: 798 Trdy = Tpub + Ipub 800 Event 4: at some later time, the DS RR corresponding to the new KSK 801 is submitted to the parent zone for publication. This time is the 802 submission time, Tsub. 804 Event 5: the DS record is published in the parent zone. As this is 805 the point at which all information for authentication - both DNSKEY 806 and DS record - is available in the two zones, it is the active time 807 of the key: 809 Tact = Tsub + Dreg 811 ... where Dreg is the registration delay, the time taken after the DS 812 record has been received by the parent zone manager for it to be 813 placed in the zone. (Parent zones are often managed by different 814 entities, and this term accounts of the organisational overhead of 815 transferring a record.) 817 Event 6: at some time later, all validating resolvers that have the 818 DS RRset cached will have a copy that includes the new DS record. 819 For the second or subsequent DS records, this interval is given by 820 the expression: 822 DprpP + TTLds 824 ... where DprpP is the propagation delay in the parent zone and TTLds 825 the TTL assigned to DS records in that zone. 827 In the case of the first DS record for the zone in question, the 828 expression is slightly different because it is not information about 829 a DS RRset that may be cached, it is information about its absence. 830 In this case, the interval is: 832 DprpP + IngcP 834 where IngcP is the negative cache interval from the zone's SOA 835 record, calculated according to [RFC2308] as the minimum of the TTL 836 of the parent SOA record itself (TTLsoaP), and the "minimum" field in 837 the record's parameters (SOAminP), i.e. 839 IngcP = min(TTLsoaP, SOAminP) 841 Event 7: while key N is active, thought needs to be given to its 842 successor (key N+1). At some time before the scheduled end of the 843 KSK lifetime, the successor KSK is introduced into the zone and is 844 used to sign the DNSKEY RRset. (As before, this means that the 845 DNSKEY RRset is signed by both the current and successor KSK.) This 846 is the publication time of the successor key, TpubS. 848 Event 8: after an interval Ipub, the successor key becomes ready (in 849 that all validating resolvers that have a copy of the DNSKEY RRset 850 have a copy of this key). This is the successor ready time, TrdyS. 852 Event 9: at the successor submission time (TsubS), the DS record 853 corresponding to the successor key is submitted to the parent zone. 855 Event 10: the successor DS record is published in the parent zone and 856 the current DS record withdrawn. The current key is said to be 857 retired and the time at which this occurs is Tret, given by: 859 The relationships between these times are: 861 TpubS <= Tact + Lksk - Dreg - Ipub 863 Tret = Tact + Lksk 865 ... where Lksk is the scheduled lifetime of the KSK. 867 Event 11: key N must remain in the zone until any validators that 868 have the DS RRset cached have a copy of the DS RRset containing the 869 new DS record. This interval is the retire interval, given by: 871 Iret = DprpP + TTLds 873 ... where DprpP is the propagation delay in the parent zone and TTLds 874 the TTL of a DS record. 876 As the key is no longer used for anything, it can also be said to be 877 dead, in which case: 879 Tdea = Tret + Iret 881 Event 12: at some later time, key N is removed from the zone (at the 882 remove time Trem); the key is now said to be removed. 884 Trem >= Tdea 886 3.3.2. Double-DS Method 888 The Double-DS method is the reverse of the Double-Signature method is 889 that it is the DS record that is pre-published (in the parent), and 890 not the DNSKEY. 892 The timeline for the key rollover is shown below: 894 |1| |2| |3| |4| |5| |6| 895 | | | | | | 896 Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - 897 | | | | | | 898 Key N+1 | | | | |<---->|<--Dreg+IpubP- - - 899 | | | | | | 900 Tgen Tsub Tpub Trdy Tact TsubS 902 ---- Time ----> 904 (continued...) 906 |7| |8| |9| |10| 907 | | | | 908 Key N - - -----Lksk---------->|<-Iret->| | 909 | | | | 910 Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - 911 | | | | 912 TrdyS Tret Tdea Trem 914 ---- Time ----> 916 Figure 5: Timeline for a Double-DS KSK rollover. 918 Event 1: key N is generated at time Tgen. As before, although there 919 is no reason why the key cannot be generated immediately prior to 920 publication, some implementations may find it convenient to create a 921 central pool of keys and draw from it. For this reason, it is again 922 shown as a separate event. 924 Event 2: the DS record corresponding to key N is submitted for 925 publication in the parent zone. This time is the submission time 926 (Tsub). 928 Event 3: after the registration delay, Dreg, the DS record is 929 published in the parent zone. This is the publication time Tpub, 930 given by: 932 Tpub = Tsub + Dreg 934 Event 4: at some later time, any validating resolver that has copies 935 of the DS RRset in its cache will have a copy of the DS record for 936 key N. At this point, key N, if introduced into the DNSKEY RRset, 937 could be used to validate the zone. For this reason, this time is 938 known as the key's ready time, Trdy, and is given by: 940 Trdy = Tpub + IpubP 942 IpubP is the parent publication interval and is given by the 943 expression: 945 IpubP = DprpP + TTLds 947 ... where DprpP is the propagation delay in the parent zone and TTLds 948 the TTL assigned to DS records in that zone. 950 Event 5: at some later time, the key rollover takes place. The 951 predecessor key is withdrawn from the DNSKEY RRset and the new key 952 (key N) introduced and used to sign the RRset. 954 As both DS records have been in the parent zone long enough to ensure 955 that they are in the cache of any validating resolvers that have the 956 DS RRset cached, the zone can be authenticated throughout the 957 rollover - either the resolver has a copy of the DNSKEY RRset (and 958 associated RRSIGs) authenticated by the predecessor key, or it has a 959 copy of the updated RRset authenticated with the new key. 961 This time is the key's active time (Tact) and at this point the key 962 is said to be active. 964 Event 6: at some point thought must be given to key replacement. The 965 DS record for the successor key must be submitted to the parent zone 966 at a time such that when the current key is withdrawn, any validating 967 resolver that has DS records in its cache will have data about the DS 968 record of the successor key. The time at which this occurs is the 969 submission time of the successor, given by: 971 TsubS <= Tact + Lksk - IpubP - Dreg 973 ... where Lksk is the lifetime of the KSK. 975 Event 7: the successor key (key N+1) enters the ready state i.e. its 976 DS record is now in the caches of all validating resolvers that have 977 the parent DS RRset cached. (This is the ready time of the 978 successor, TrdyS.) 980 Event 8: when the current key has been active for its lifetime 981 (Lksk), the current key is removed from the DNSKEY RRset and the 982 successor key added; the RRset is then signed with the successor key. 983 This point is the retire time of the key, Tret, given by: 985 Tret = Tact + Lksk 987 Event 9: at some later time, all copies of the old DNSKEY RRset have 988 expired from caches and the old DS record is no longer needed. This 989 is called the dead time, Tdea, and is given by: 991 Tdea = Tret + Iret 993 ... where Iret is the retire interval, given by: 995 Iret = Dprp + TTLkey 997 As before, this term includes the time taken to propagate the RRset 998 change through the master-slave hierarchy and the time take for the 999 DNSKEY RRset to expire from caches. 1001 Event 10: at some later time, the DS record is removed from the 1002 parent zone. This is the removal time (Trem), given by: 1004 Trem >= Tdea 1006 3.3.3. Double-RRset Method 1008 In the Double-RRset method, both the DS and DNSKEY records are 1009 changed at the same time, so for a period the zone can be 1010 authenticated with either key. The advantage of this method is its 1011 applicability in cases where zone management policy requires overlap 1012 of authentication keys during a roll. 1014 The timeline for this rollover is shown below: 1016 |1| |2| |3| |4| |5| |6| |7| 1017 | | | | | | | 1018 Key N | |<-Dreg->|<-----Lksk----->|<-Iret->| | 1019 | | | | | | | 1020 Key N+1 | | | |<-Dreg->|<-----Lksk-- - - 1021 | | | | | | | 1022 Tgen Tpub Tact TpubS Tret Tdea Trem 1024 ---- Time ----> 1026 Figure 6: Timeline for a Double-RRset KSK rollover. 1028 Event 1: key N is created at time Tgen and thereby immediately 1029 becomes generated. As before, although there is no reason why the 1030 key cannot be generated immediately prior to publication, some 1031 implementations may find it convenient to create a central pool of 1032 keys and draw from it. For this reason, it is again shown as a 1033 separate event. 1035 Event 2: the key is added to and used for signing the DNSKEY RRset 1036 and is thereby published in the zone. At the same time the 1037 corresponding DS record is submitted to the parent zone for 1038 publication. This time is the publish time (Tpub) and the key is now 1039 said to be published. 1041 Event 3: after Dreg, the registration delay, the DS record is 1042 published in the parent zone. At this point, the zones have all the 1043 information needed for a validating resolver to authenticate the 1044 zone, although the information may not yet have reached all 1045 validating resolver caches. This time is the active time (Tact) and 1046 the key is said to be active. 1048 Tact = Tpub + Dreg 1050 Event 4: at some point we need to give thought to key replacement. 1051 The successor key must be introduced into the zone (and its DS record 1052 submitted to the parent) at a time such that it becomes active when 1053 the current key has been active for its lifetime, Lksk. This time is 1054 TpubS, the publication time of the successor key, and is given by: 1056 TpubS <= Tact + Lksk - Dreg 1058 ... where Lksk is the lifetime of the KSK. 1060 Event 5: the successor key's DS record appears in the parent zone and 1061 the successor key becomes active. At this point, the current key 1062 becomes retired. This occurs at Tret, given by: 1064 Tret = Tact + Lksk 1066 Event 6: the current DNSKEY and DS record must be retained in the 1067 zones until any any validating resolver that has cached the DNSKEY 1068 and/or DS RRsets will have a copy of the data for the successor key. 1069 At this point the current key information is dead, as any validating 1070 resolver can perform authentication using the successor key. This is 1071 the dead time, Tdea, given by: 1073 Tdea = Tret + Iret 1075 ... where Iret is the retire interval. This depends on how long both 1076 the successor DNSKEY and DS records take to propagate through the 1077 nameserver infrastructure and thence into validator caches. These 1078 delays are the publication intervals of the child and parent zones 1079 respectively, so a suitable expression for Iret is: 1081 Iret = max(IpubP, IpubC) 1083 IpubC is the publication interval of the DNSKEY in the child zone, 1084 IpubP that of the DS record in the parent. 1086 The child term comprises two parts - the time taken for the 1087 introduction of the DNSKEY record to be propagated to the downstream 1088 secondary servers (= DprpC, the child propagation delay) and the time 1089 taken for information about the DNSKEY RRset to expire from the 1090 validating resolver cache, i.e. 1092 IpubC = DprpC + TTLkey 1094 TTLkey is the TTL for a DNSKEY record in the child zone. The parent 1095 term is similar: 1097 IpubP = DprpP + TTLds 1099 DprpP the propagation delay in the parent zone and TTLds the TTL for 1100 a DS record in the parent zone. 1102 Event 7: at some later time, the DNSKEY record can be removed from 1103 the child zone and a request can be made to remove the DS record from 1104 the parent zone. This is the removal time, Trem and is given by: 1106 Trem >= Tdea 1108 3.3.4. Interaction with Configured Trust Anchors 1110 Although the preceding sections have been concerned with rolling KSKs 1111 where the trust anchor is a DS record in the parent zone, zone 1112 managers may want to take account of the possibility that some 1113 validating resolvers may have configured trust anchors directly. 1115 Rolling a configured trust anchor is dealt with in [RFC5011]. It 1116 requires introducing the KSK to be used as the trust anchor into the 1117 zone for a period of time before use, and retaining it (with the 1118 "revoke" bit set) for some time after use. The Double-Signature and 1119 Double-RRset methods can be adapted to include [RFC5011] 1120 recommendations so that the rollover will also be signalled to 1121 validating resolvers with configured trust anchors. (The 1122 recommendations are not suitable for the Double-DS method. 1123 Introducing the new key early and retaining the old key after use 1124 effectively converts it into a form of Double-RRset.) 1126 3.3.4.1. Addition of KSK 1128 When the new key is introduced, the publication interval (Ipub) in 1129 the Double-Signature method should also be subject to the condition: 1131 Ipub >= max(30 days, TTLkey) 1133 ... where the right had side of the expression is the add hold-down 1134 time defined in section 2.4.1 of [RFC5011]. 1136 In the Double-RRSIG method, the key should not be regarded as being 1137 active until the add hold-down time has passed. In other words, the 1138 following condition should be enforced: 1140 Tact >= Tpub + max(30 days, TTLkey) 1142 (Effectively, this means extending the lifetime of the key by an 1143 appropriate amount.) 1145 3.3.4.2. Removal of KSK 1147 The timeline for the removal of the key in both methods is modified 1148 by introducing a new state, "revoked". When the key reaches the end 1149 of the retire period, instead of being declared "dead", it is 1150 revoked; the "revoke" bit is set on the DNSKEY RR and is published in 1151 (and used to sign) the DNSKEY RRset. The key is maintained in this 1152 state for the "revoke" interval, Irev, given by: 1154 Irev >= 30 days 1156 ... 30 days being the [RFC5011] remove hold-down time. After this 1157 time, the key is dead and can be removed from the zone when 1158 convenient. 1160 3.3.5. Introduction of First KSK 1162 There is an additional consideration when introducing a KSK into a 1163 zone for the first time, and that is that no validating resolver 1164 should be in a position where it can access the trust anchor before 1165 the KSK appears in the zone. To do so will cause the validating 1166 resolver to declare the zone to be bogus. 1168 This is important: in the case of a secure parent, it means ensuring 1169 that the DS record is not published in the parent zone until there is 1170 no possibility that a validating resolver can obtain the record yet 1171 not be able to obtain the corresponding DNSKEY. In the case of an 1172 insecure parent, i.e. the initial creation of a new security apex, it 1173 is important to not configure trust anchors in validating resolvers 1174 until the DNSKEY RRset has had sufficient time to propagate. In both 1175 cases, this time is the trust anchor availability time (Ttaa) given 1176 by: 1178 Ttaa >= Tpub + IpubC 1180 where 1182 IpubC = DprpC + TTLkeyC 1184 or 1186 IpubC = DprpC + IngcC 1188 The first expression applies if there was previously a DNSKEY RRset 1189 in the child zone, the expression for IpubC including the TTLkeyC 1190 term to account for the time taken for that RRset to expire from 1191 caches. (It is possible that the zone was signed but that the trust 1192 anchor had not been submitted to the parent.) 1194 If the introduction of the KSK caused the appearance of the first 1195 DNSKEY RRset in the child zone, the second expression applies in 1196 which the TTLkeyC term is replaced by Ingc to allow for the effect of 1197 negative caching. 1199 As before, IngcC is the negative cache interval from the child zone's 1200 SOA record, calculated according to [RFC2308] as the minimum of the 1201 TTL of the SOA record itself (TTLsoaC), and the "minimum" field in 1202 the record's parameters (SOAminC), i.e. 1204 IngcC = min(TTLsoaC, SOAminC) 1206 4. Standby Keys 1208 Although keys will usually be rolled according to some regular 1209 schedule, there may be occasions when an emergency rollover is 1210 required, e.g. if the active key is suspected of being compromised. 1211 The aim of the emergency rollover is to allow the zone to be re- 1212 signed with a new key as soon as possible. As a key must be in the 1213 ready state to sign the zone, having at least one additional key (a 1214 standby key) in this state at all times will minimise delay. 1216 In the case of a ZSK, a standby key only really makes sense with the 1217 Pre-Publication method. A permanent standby DNSKEY RR should be 1218 included in zone or successor keys could be introduced as soon as 1219 possible after a key becomes active. Either way results in an 1220 additional ZSK in the DNSKEY RRset that can immediately be used to 1221 sign the zone if the current key is compromised. 1223 (Although in theory the mechanism could be used with both the Double- 1224 Signature and Double-RRSIG methods, it would require Pre-Publication 1225 of the signatures. Essentially, the standby key would be permanently 1226 active, as it would have to be periodically used to renew signatures. 1227 Zones would also permanently require two sets of signatures, 1228 something that could have a performance impact in large zones.) 1230 A standby key can also be used with the Double-Signature and 1231 Double-DS methods of rolling a KSK. (The idea of a standby key in 1232 the Double-RRset effectively means having two active keys.) The 1233 Double-Signature method requires that the standby KSK be included in 1234 the DNSKEY RRset; rolling the key then requires just the introduction 1235 of the DS record in the parent. (Note that the DNSKEY should also be 1236 used to sign the DNSKEY RRset. As the RRset and its signatures 1237 travel together, merely adding the DNSKEY does not provide the 1238 desired time saving; to be used in a rollover requires that the 1239 DNSKEY RRset be signed with the standby key, and this introduces a 1240 delay whilst the RRset and its signatures propagate to the caches of 1241 validating resolvers. There is no time advantage over introducing a 1242 new DNSKEY and signing the RRset with it at the same time.) 1244 In the Double-DS method of rolling a KSK, it is not a standby key 1245 that is present, it is a standby DS record in the parent zone. 1246 Whatever algorithm is used, the standby item of data can be 1247 introduced as a permanent standby, or be a successor introduced as 1248 early as possible. 1250 5. Algorithm Considerations 1252 The preceding sections have implicitly assumed that all keys and 1253 signatures are created using a single algorithm. However, [RFC4035] 1254 (section 2.4) states that "There MUST be an RRSIG for each RRset 1255 using at least one DNSKEY of each algorithm in the zone apex DNSKEY 1256 RRset". 1258 Except in the case of an algorithm rollover - where the algorithms 1259 used to create the signatures are being changed - there is no 1260 relationship between the keys of different algorithms. This means 1261 that they can be rolled independently of one another. In other 1262 words, the key rollover logic described above should be run 1263 separately for each algorithm; the union of the results is included 1264 in the zone, which is signed using the active key for each algorithm. 1266 6. Summary 1268 For ZSKs, "Pre-Publication" is generally considered to be the 1269 preferred way of rolling keys. As shown in this document, the time 1270 taken to roll is wholly dependent on parameters under the control of 1271 the zone manager. 1273 In contrast, "Double-RRset" is the most efficient method for KSK 1274 rollover due to the ability to have new DS records and DNSKEY RRsets 1275 propagate in parallel. The time taken to roll KSKs may depend on 1276 factors related to the parent zone if the parent is signed. For 1277 zones that intend to comply with the recommendations of [RFC5011], in 1278 virtually all cases the rollover time will be determined by the 1279 RFC5011 "add hold-down" and "remove hold-down" times. It should be 1280 emphasized that this delay is a policy choice and not a function of 1281 timing values and that it also requires changes to the rollover 1282 process due to the need to manage revocation of trust anchors. 1284 Finally, the treatment of emergency key rollover is significantly 1285 simplified by the introduction of stand-by keys as standard practice 1286 during all types of rollovers. 1288 7. IANA Considerations 1290 This memo includes no request to IANA. 1292 8. Security Considerations 1294 This document does not introduce any new security issues beyond those 1295 already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. 1297 9. Acknowledgements 1299 The authors gratefully acknowledge help and contributions from Roy 1300 Arends and Wouter Wijngaards. 1302 10. Change History 1304 o draft-morris-dnsop-dnssec-key-timing-02 1305 * General restructuring. 1306 * Added descriptions of more rollovers (IETF-76 meeting). 1307 * Improved description of key states and removed diagram. 1308 * Provided simpler description of standby keys. 1309 * Added section concerning first key in a zone. 1310 * Moved [RFC5011] to a separate section. 1311 * Various nits fixed (Alfred Hones, Jeremy Reed, Scott Rose, Sion 1312 Lloyd, Tony FinchX). 1314 o draft-morris-dnsop-dnssec-key-timing-01 1315 * Use latest boilerplate for IPR text. 1316 * List different ways to roll a KSK (acknowledgements to Mark 1317 Andrews). 1318 * Restructure to concentrate on key timing, not management 1319 procedures. 1320 * Change symbol notation (Diane Davidowicz and others). 1321 * Added key state transition diagram (Diane Davidowicz). 1322 * Corrected spelling, formatting, grammatical and style errors 1323 (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya). 1324 * Added note that in the case of multiple algorithms, the 1325 signatures and rollovers for each algorithm can be considered as 1326 more or less independent (Alfred Hoenes). 1327 * Take account of the fact that signing a zone is not atomic 1328 (Chris Thompson). 1329 * Add section contrasting pre-publication rollover with double 1330 signature rollover (Matthijs Mekking). 1331 * Retained distinction between first and subsequent keys in 1332 definition of initial publication interval (Matthijs Mekking). 1334 o draft-morris-dnsop-dnssec-key-timing-00 1335 Initial draft. 1337 11. References 1338 11.1. Normative References 1340 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1341 NCACHE)", RFC 2308, March 1998. 1343 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1344 Rose, "DNS Security Introduction and Requirements", 1345 RFC 4033, March 2005. 1347 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1348 Rose, "Resource Records for the DNS Security Extensions", 1349 RFC 4034, March 2005. 1351 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1352 Rose, "Protocol Modifications for the DNS Security 1353 Extensions", RFC 4035, March 2005. 1355 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1356 Trust Anchors", RFC 5011, September 2007. 1358 11.2. Informative References 1360 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1361 RFC 4641, September 2006. 1363 Appendix A. List of Symbols 1365 The document defines a number of symbols, all of which are listed 1366 here. All are of the form: 1368 All symbols used in the text are of the form: 1370 1372 where: 1374 is an upper-case character indicating what type the symbol is. 1375 Defined types are: 1377 D delay: interval that is a feature of the process 1379 I interval between two events 1381 L lifetime: interval set by the zone manager 1382 SOA parameter related to SOA RR 1384 T a point in time 1386 TTL TTL of a record 1388 T and I are self-explanatory. D, and L are also time periods, but 1389 whereas I values are intervals between two events (even if the events 1390 are defined in terms of the interval, e.g. the dead time occurs 1391 "retire interval" after the retire time), D, and L are fixed 1392 intervals. An "L" interval (lifetime) is chosen by the zone manager 1393 and is a feature of policy. A "D" interval (delay) is a feature of 1394 the process, probably outside control of the zone manager. SOA and 1395 TTL are used just because they are common terms. 1397 is lower-case and defines what object or event the variable is 1398 related to, e.g. 1400 act active 1402 ngc negative cache 1404 pub publication 1406 Finally, is a capital letter that distinguishes between the 1407 same variable applying to different instances of an object and is one 1408 of: 1410 C child 1412 G signature 1414 K key 1416 P parent 1418 S successor 1420 The list of variables used in the text is: 1422 Dprp Propagation delay. The amount of time for a change made at 1423 a master nameserver to propagate to all the slave 1424 nameservers. 1426 DprpC Propagation delay in the child zone. 1428 DprpP Propagation delay in the parent zone. 1430 Dreg Registration delay. As a parent zone is often managed by a 1431 different organisation to that managing the child zone, the 1432 delays associated with passing data between zones is 1433 captured by this term. 1435 Dskw Clock skew. The maximum difference in time between the 1436 signing system and the resolver. 1438 Dsgn Signing delay. After the introduction of a new ZSK, the 1439 amount of time taken for all the RRs in the zone to be 1440 signed with it. 1442 Ingc Negative cache interval. 1444 IngcP Negative cache interval of the child zone. 1446 IngcP Negative cache interval of the parent zone. 1448 Ipub Publication interval. The amount of time that must elapse 1449 after the publication of a key before it can be considered 1450 to have entered the ready state. 1452 IpubC Publication interval in the child zone. 1454 IpubG Publication interval for the signature. 1456 IpubK Publication interval for the key. 1458 IpubP Publication interval in the parent zone. 1460 Iret Retire interval. The amount of time that must elapse after 1461 a key enters the retire state for any signatures created 1462 with it to be purged from validating resolver caches. 1464 Irev Revoke interval. The amount of time that a KSK must remain 1465 published with the revoke bit set to satisfy [RFC5011] 1466 considerations. 1468 Lksk Lifetime of a key-signing key. This is the intended amount 1469 of time for which this particular KSK is regarded as the 1470 active KSK. Depending on when the key is rolled-over, the 1471 actual lifetime may be longer or shorter than this. 1473 Lzsk Lifetime of a zone-signing key. This is the intended 1474 amount of time for which the ZSK is used to sign the zone. 1475 Depending on when the key is rolled-over, the actual 1476 lifetime may be longer or shorter than this. 1478 Lsig Lifetime of a signature: the difference in time between the 1479 signature's expiration time and the time at which the 1480 signature was created. (Note that this is not the 1481 difference between the signature's expiration and inception 1482 times: the latter is usually set a small amount of time 1483 before the signature is created to allow for clock skew 1484 between the signing system and the validating resolver.) 1486 SOAmin Value of the "minimum" field from an SOA record. 1488 SOAminC Value of the "minimum" field from an SOA record in the 1489 child zone. 1491 SOAminP Value of the "minimum" field from an SOA record in the 1492 parent zone. 1494 Tact Active time of the key; the time at which the key is 1495 regarded as the principal key for the zone. 1497 TactS Active time of the successor key. 1499 Tdea Dead time of a key. Applicable only to ZSKs, this is the 1500 time at which any record signatures held in validating 1501 resolver caches are guaranteed to be created with the 1502 successor key. 1504 Tgen Generate time of a key. The time that a key is created. 1506 Tpub Publish time of a key. The time that a key appears in a 1507 zone for the first time. 1509 TpubS Publish time of the successor key. 1511 Trem Removal time of a key. The time at which a key is removed 1512 from the zone. 1514 Tret Retire time of a key. The time at which a successor key 1515 starts being used to sign the zone. 1517 Trdy Ready time of a key. The time at which it can be 1518 guaranteed that validating resolvers that have key 1519 information from this zone cached have a copy of this key 1520 in their cache. (In the case of KSKs, should the 1521 validating resolvers also have DS information from the 1522 parent zone cached, the cache must include information 1523 about the DS record corresponding to the key.) 1525 TrdyS Ready time of a successor key. 1527 Tsub Submit time - the time at which the DS record of a KSK is 1528 submitted to the parent. 1530 TsubS Submit time of the successor key. 1532 TTLds Time to live of a DS record (in the parent zone). 1534 TTLkey Time to live of a DNSKEY record. 1536 TTLkeyC Time to live of a DNSKEY record in the child zone. 1538 TTLsoa Time to live of a SOA record. 1540 TTLsoaC Time to live of a SOA record in the child zone. 1542 TTLsoaP Time to live of a SOA record in the parent zone. 1544 TTLsig Time to live of an RRSIG record. 1546 Ttaa Trust anchor availability time. The time at which a trust 1547 anchor record can be made available when a KSK is first 1548 introduced into a zone. 1550 Authors' Addresses 1552 Stephen Morris 1553 Internet Systems Consortium 1554 950 Charter Street 1555 Redwood City, CA 94063 1556 USA 1558 Phone: +1 650 423 1300 1559 Email: stephen@isc.org 1560 Johan Ihren 1561 Netnod 1562 Franzengatan 5 1563 Stockholm, SE-112 51 1564 Sweden 1566 Phone: +46 8615 8573 1567 Email: johani@autonomica.se 1569 John Dickinson 1570 Sinodun Internet Technologies Ltd 1571 Stables 4 Suite 11, Howbery Park 1572 Wallingford, Oxfordshire OX10 8BA 1573 UK 1575 Phone: +44 1491 818120 1576 Email: jad@sinodun.com