idnits 2.17.1 draft-morris-dnsop-dnssec-key-timing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** 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 1260: '...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 (March 5, 2010) is 5158 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: 2 errors (**), 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 Nominet 4 Intended status: Informational J. Ihren 5 Expires: September 6, 2010 Netnod 6 J. Dickinson 7 Sinodun Internet Technologies Ltd 8 March 5, 2010 10 DNSSEC Key Timing Considerations 11 draft-morris-dnsop-dnssec-key-timing-02.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 to IETF 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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 6, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 62 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 67 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 69 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 71 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 72 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 13 73 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 14 74 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17 75 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 17 76 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 20 77 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 22 78 3.3.4. Interaction with Configured Trust Anchors . . . . . . 25 79 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 25 80 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 25 81 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 26 82 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28 84 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 88 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 92 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 30 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 95 1. Introduction 97 1.1. Key Rolling Considerations 99 When a zone is secured with DNSSEC, the zone manager must be prepared 100 to replace ("roll") the keys used in the signing process. The 101 rolling of keys may be caused by compromise of one or more of the 102 existing keys, or it may be due to a management policy that demands 103 periodic key replacement for security or operational reasons. In 104 order to implement a key rollover, the keys need to be introduced 105 into and removed from the zone at the appropriate times. 106 Considerations that must be taken into account are: 108 o DNSKEY records and associated information (such as RRSIG records 109 created with the key or the associated DS records) are not only 110 held at the authoritative nameserver, they are also cached at 111 client resolvers. The data on these systems can be interlinked, 112 e.g. a validating resolver may try to validate a signature 113 retrieved from a cache with a key obtained separately. 115 o A query for the key RRset returns all DNSKEY records in the zone. 116 As there is limited space in the UDP packet (even with EDNS0 117 support), dead key records must be periodically removed. (For the 118 same reason, the number of stand-by keys in the zone should be 119 restricted to the minimum required to support the key management 120 policy.) 122 o Zone "boot-strapping" events, where a zone is signed for the first 123 time, can be common in configurations where a large number of 124 zones are being served. Procedures should be able to cope with 125 the introduction of keys into the zone for the first time as well 126 as "steady-state", where the records are being replaced as part of 127 normal zone maintenance. 129 o To allow for an emergency re-signing of the zone as soon as 130 possible after a key compromise has been detected, stand-by keys 131 (additional keys over and above those used to sign the zone) need 132 to be present. 134 Management policy, e.g. how long a key is used for, also needs to be 135 considered. However, the point of key management logic is not to 136 ensure that a "rollover" is completed at a certain time but rather to 137 ensure that no changes are made to the state of keys published in the 138 zone until it is "safe" to do so ("safe" in this context meaning that 139 at no time during the rollover process does any part of the zone ever 140 go bogus). In other words, although key management logic enforces 141 policy, it may not enforce it strictly. 143 1.2. Types of Keys 145 Although DNSSEC validation treats all keys equally, [RFC4033] 146 recognises the broad classification of zone-signing keys (ZSK) and 147 key-signing keys (KSK). A ZSK is used to authenticate information 148 within the zone; a KSK is used to authenticate the key set in the 149 zone. The main implication for this distinction concerns the 150 consistency of information during a rollover. 152 During operation, a validating resolver must use separate pieces of 153 information to perform an authentication. At the time of 154 authentication, each piece of information may be in the validating 155 resolver's cache or may need to be retrieved from the authoritative 156 server. The rollover process needs to happen in such a way that at 157 all times through the rollover the information is consistent. With a 158 ZSK, the information is the RRSIG (plus associated RRset) and the 159 DNSKEY. These are both obtained from the same zone. In the case of 160 the KSK, the information is the DNSKEY and DS RRset with the latter 161 being obtained from a different zone. 163 There are similarities in the rolling of ZSKs and KSKs: replace the 164 RRSIG (plus RR) by the DNSKEY and replace the DNSKEY by the DS, and 165 the ZSK rolling algorithms are virtually the same as the KSK 166 algorithms. However, there are a number of differences, and for this 167 reason the two types of rollovers are described separately in this 168 document. 170 1.3. Terminology 172 The terminology used in this document is as defined in [RFC4033] and 173 [RFC5011]. 175 A large number of symbols are used to identify times, intervals, etc. 176 All are listed in Appendix A. 178 2. Rollover Methods 180 2.1. ZSK Rollovers 182 A ZSK can be rolled in one of three ways: 184 o Pre-Publication. Described in [RFC4641], the new key is 185 introduced into the DNSKEY RRset, leaving the existing keys and 186 signatures in place. This state of affairs remains in place for 187 long enough to ensure that any DNSKEY RRsets cached in client 188 validating resolvers contain both keys. At that point signatures 189 created with the old key can be replaced by those created with the 190 new key, and the old signatures removed. During the re-signing 191 process (which may or may not be atomic depending on how the zone 192 is managed), it doesn't matter which key an RRSIG record retrieved 193 by a client was created with; clients with a cached copy of the 194 DNSKEY RRset will have a copy containing both the old and new 195 keys. 197 Once the zone contains only signatures created with the new key, 198 there is an interval during which RRSIG records created with the 199 old key expire from client caches. After this, there will be no 200 signatures anywhere that were created using the old key, and it 201 can can be removed from the DNSKEY RRset. 203 o Double-Signature. Also mentioned in [RFC4641], this involves 204 introducing the new key into the zone and using it to create 205 additional RRSIG records; the old key and existing RRSIG records 206 are retained. During the period in which the zone is being signed 207 (again, the signing process may not be atomic), client resolvers 208 are always able to validate RRSIGs: any combination of old and new 209 DNSKEY RRset and RRSIG allows at least one signature to be 210 validated. 212 Once the signing process is complete and enough time has elapsed 213 to allow all old information to expire from caches, the old key 214 and signatures can be removed from the zone. As before, during 215 this period any combination of DNSKEY RRset and RRSIG will allow 216 validation of at least one signature. 218 o Double-RRSIG. Strictly speaking, the use of the term "Double- 219 Signature" above is a misnomer as the method is not only double 220 signature, it is also double key as well. A true Double-Signature 221 method (here called the Double-RRSIG method) involves introducing 222 new signatures in the zone (while still retaining the old ones) 223 but not the new key. 225 Once the signing process is complete and enough time has elapsed 226 to ensure that all caches that may contain an RR and associated 227 RRSIG to have a copy of both signatures, the ZSK is changed. 228 After a further interval during which the old DNSKEY RRset expires 229 from caches, the old signatures are removed from the zone. 231 Of three methods, Double-Signature is the simplest conceptually - 232 introduce the new key and new signatures, then approximately one TTL 233 later remove the old key and signatures. The drawback of this method 234 is a noticeable increase in the size of the DNSSEC data, affecting 235 both the overall size of the zone and the size of the responses. 237 Pre-Publication is more complex - introduce the new key, 238 approximately one TTL later sign the records, and approximately one 239 TTL after that remove the old key. However, the amount of DNSSEC 240 data is kept to a minimum which reduces the impact on performance. 242 The Double-RRSIG combines the increase in data volume of the Double- 243 Signature method with the complexity of Pre-Publication. It has few 244 (if any) advantages and a description is only included here for 245 completeness. 247 2.2. KSK Rollovers 249 In the ZSK case the issue for the validating resolver is to ensure 250 that it has access to the ZSK that corresponds to a particular 251 signature. In the KSK case this can never be a problem as the KSK is 252 only used for one signature (that over the DNSKEY RRset) and both the 253 key the signature travel together. Instead, the issue is to ensure 254 that the KSK is trusted. 256 Trust in the KSK is either due to the existence of an explicitly 257 configured trust anchor in the validating resolver or DS record in 258 the parent zone (which is itself trusted). If the former, [RFC5011] 259 timings will be needed to roll the keys. If the latter, the rollover 260 algorithm will need to involve the parent zone in the addition and 261 removal of DS records, so timings are not wholly under the control of 262 the zone manager. (The zone manager may elect to include [RFC5011] 263 timings in the key rolling process so as to cope with the possibility 264 that the key has also been explicitly configured as a trust anchor.) 266 It is important to note that this does not preclude the development 267 of key rollover logic; in accordance with the goal of the rollover 268 logic being able to determine when a state change is "safe", the only 269 effect of being dependent on the parent is that there may be a period 270 of waiting for the parent to respond in addition to any delay the key 271 rollover logic requires. Although this introduces additional delays, 272 even with a parent that is less than ideally responsive the only 273 effect will be a slowdown in the rollover state transitions. This 274 may cause a policy violation, but will not cause any operational 275 problems. 277 Like the ZSK case, there are three methods for rolling a KSK: 279 o Double-Signature: Also known as Double-DNSKEY, the new KSK is 280 added to the DNSKEY RRset which is then signed with both the old 281 and new key. After waiting for the old RRset to expire from 282 caches, the DS record in the parent zone is changed. After 283 waiting a further interval for this change to be reflected in 284 caches, the old key is removed from the RRset. (The name "Double- 285 Signature" is used because, like the ZSK method of the same name, 286 the new key is introduced and immediately used for signing.) 288 o Double-DS: the new DS record is published. After waiting for this 289 change to propagate into the caches of all validating resolvers, 290 the KSK is changed. After a further interval during which the old 291 DNSKEY RRset expires from caches, the old DS record is removed. 293 o Double-RRset: the new KSK is added to the DNSKEY RRset which is 294 then signed with both the old and new key, and the new DS record 295 added to the parent zone. After waiting a suitable interval for 296 the old DS and DNSKEY RRsets to expire from validating resolver 297 caches, the old DNSKEY and DS record are removed. 299 In essence, "Double-Signature" means that the new KSK is introduced 300 first and used to sign the DNSKEY RRset. The DS record is changed, 301 and finally the old KSK removed. With "Double-DS" it is the other 302 way around. Finally, Double-RRset does both updates more or less in 303 parallel. 305 The strategies have different advantages and disadvantages: 307 o Double-Signature minimizes the number of interactions with the 308 parent zone. However, for the period of the rollover the DNSKEY 309 RRset is signed with two KSKs, so increasing the size of the 310 response to a query for this data. 312 o Double-DS keeps the size of the DNSKEY RRset to a minimum, but 313 does require the additional administrative overhead of two 314 interactions with the parent to roll a KSK. (Although this can be 315 mitigated if the parent has the ability for a child zone to 316 schedule the withdrawal of the old key at the same time as the 317 introduction of the new one.) 319 o Finally, Double-RRset allows the rollover to be done in roughly 320 half the time of the other two methods; it also supports policies 321 that require a period of running with old and new KSKs 322 simultaneously. However, it does have the disadvantages of both 323 the other two methods - it requires two signatures during the 324 period of the rollover and two interactions with the parent. 326 2.3. Summary 328 The methods can be summarised as follows: 330 +------------------+------------------+-----------------------------+ 331 | ZSK Method | KSK Method | Description | 332 +------------------+------------------+-----------------------------+ 333 | Pre-Publication | (not applicable) | Publish the DNSKEY before | 334 | | | the RRSIG. | 335 | Double-Signature | Double-Signature | Publish the DNSKEY and | 336 | | | RRSIG at same time. (For a | 337 | | | KSK, this happens before | 338 | | | the DS is published.) | 339 | Double-RRSIG | (not applicable) | Publish RRSIG before the | 340 | | | DNSKEY. | 341 | (not applicable) | Double-DS | Publish DS before the | 342 | | | DNSKEY. | 343 | (not applicable) | Double-RRset | Publish DNSKEY and DS in | 344 | | | parallel. | 345 +------------------+------------------+-----------------------------+ 347 Table 1 349 3. Key Rollover Timelines 351 3.1. Key States 353 During the rolling process, a key moves through different states. 354 These states are: 356 Generated The key has been created, but has not yet been used for 357 anything. 359 Published The DNSKEY record - or information associated with it - 360 is published in the zone, but predecessors of the key (or 361 associated information) may be held in resolver caches. 363 The idea of "associated information" is used in rollover 364 methods where RRSIG or DS records are published first and 365 the DNSKEY is changed in an atomic operation. It allows 366 the rollover still to be thought of as moving through a 367 set of states. In the rest of this section, the term 368 "key" should be taken to mean "key or associated 369 information". 371 Ready The key has been published for long enough to guarantee 372 that all caches that might contain a copy of the key 373 RRset have a copy that includes this key. 375 Active The key is in the zone and has started to be used to sign 376 RRsets or authenticate the DNSKEY RRset. Note that when 377 this state is entered, it might not be possible for every 378 validating resolver to use the key for validation: the 379 zone signing may not have finished, or the data might not 380 have reached the resolver because of propagation delays 381 and/or caching issues. If this is the case, the resolver 382 will have to rely on the key's predecessor instead. 384 Retired The key is in the zone but a successor key has become 385 active. As there may still be information in caches that 386 that require use of the key, it is being retained until 387 this information expires. 389 Dead The key is published in the zone but there is no 390 information anywhere that requires its presence. 392 Removed The key has been removed from the zone. 394 There is one additional state, used where [RFC5011] considerations 395 are in effect (see Section 3.3.4): 397 Revoked The key is published for a period with the "revoke" bit 398 set as a way of notifying validating resolvers that have 399 configured it as a trust anchor that it is about to be 400 removed from the zone. 402 3.2. Zone-Signing Key Timelines 404 3.2.1. Pre-Publication Method 406 The following diagram shows the time line of a particular ZSK and its 407 replacement by its successor using the Pre-Publication method. Time 408 increases along the horizontal scale from left to right and the 409 vertical lines indicate events in the life of the key. The events 410 are numbered; significant times and time intervals are marked. 412 |1| |2| |3| |4| |5| |6| |7| |8| |9| 413 | | | | | | | | | 414 Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| 415 | | | | | | | | | 416 Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - 417 | | | | | | | | | 418 Tgen Tpub Trdy Tact TpubS Tret Tdea Trem 420 ---- Time ----> 422 Figure 1: Timeline for a Pre-Publication ZSK rollover. 424 Event 1: key N is generated at the generate time (Tgen). Although 425 there is no reason why the key cannot be generated immediately prior 426 to publication in the zone (Event 2), some implementations may find 427 it convenient to create a pool of keys in one operation and draw from 428 that pool as required. For this reason, it is shown as a separate 429 event. Keys that are available for use but not published are said to 430 be generated. 432 Event 2: key N's DNSKEY record is put into the zone, i.e. it is added 433 to the DNSKEY RRset which is then re-signed with the current key- 434 signing key. The time at which this occurs is the key's publication 435 time (Tpub), and the key is now said to be published. Note that the 436 key is not yet used to sign records. 438 Event 3: before it can be used, the key must be published for long 439 enough to guarantee that any resolver that has a copy of the DNSKEY 440 RRset from the zone in its cache will have a copy of the RRset that 441 includes this key: in other words, that any prior cached information 442 about the DNSKEY RRset has expired. 444 This interval is the publication interval (Ipub) and, for the second 445 or subsequent keys in the zone, is given by: 447 Ipub = Dprp + TTLkey 449 Here, Dprp is the propagation delay - the time taken for any change 450 introduced at the master to replicate to all slave servers - which 451 depends on the depth of the master-slave hierarchy. TTLkey is the 452 time-to-live (TTL) for the DNSKEY records in the zone. The sum is 453 therefore the time taken for existing DNSKEY records to expire from 454 the caches of downstream validating resolvers, regardless of the 455 nameserver from which they were retrieved. 457 In the case of the first key in the zone, Ipub is slightly different 458 because it is not information about a DNSKEY RRset that may be 459 cached, it is information about its absence. In this case: 461 Ipub = Dprp + Ingc 463 where Ingc is the negative cache interval from the zone's SOA record, 464 calculated according to [RFC2308] as the minimum of the TTL of the 465 SOA record itself (TTLsoa), and the "minimum" field in the record's 466 parameters (SOAmin), i.e. 468 Ingc = min(TTLsoa, SOAmin) 470 After a delay of Ipub, the key is said to be ready and could be used 471 to sign records. The time at which this event occurs is the key's 472 ready time (Trdy), which is given by: 474 Trdy = Tpub + Ipub 476 Event 4: at some later time, the key starts being used to sign 477 RRsets. This point is the active time (Tact) and after this, the key 478 is said to be active. 480 Event 5: while this key is active, thought must be given to its 481 successor (key N+1). As with the introduction of the currently 482 active key into the zone, the successor key will need to be published 483 at least Ipub before it is used. Denoting the publication time of 484 the successor key by TpubS, then: 486 TpubS <= Tact + Lzsk - Ipub 488 Here, Lzsk is the length of time for which a ZSK will be used (the 489 ZSK lifetime). It should be noted that unlike the publication 490 interval, Lzsk is not determined by timing logic, but by key 491 management policy. Lzsk will be set by the operator according to 492 their assessment of the risks posed by continuing to use a key and 493 the risks associated with key rollover. However, operational 494 considerations may mean a key is active for slightly more or less 495 than Lzsk. 497 Event 6: while the key N is still active, its successor becomes 498 ready. From this time onwards, it could be used to sign the zone. 500 Event 7: at some point the decision is made to start signing the zone 501 using the successor key. This will be when the current key has been 502 in use for an interval equal to the ZSK lifetime, hence: 504 Tret = Tact + Lzsk 506 This point in time is the retire time (Tret) of key N; after this the 507 key is said to be retired. (This time is also the point at which the 508 successor key becomes active.) 510 Event 8: the retired key needs to be retained in the zone whilst any 511 RRSIG records created using this key are still published in the zone 512 or held in resolver caches. (It is possible that a resolver could 513 have an unexpired RRSIG record and an expired DNSKEY RRset in the 514 cache when it is asked to provide both to a client. In this case the 515 DNSKEY RRset would need to be looked up again.) This means that once 516 the key is no longer used to sign records, it should be retained in 517 the zone for at least the retire interval (Iret) given by: 519 Iret = Dsgn + Dprp + TTLsig 521 Dsgn is the delay needed to ensure that all existing RRsets have been 522 re-signed with the new key. Dprp is (as described above) the 523 propagation delay, required to guarantee that the updated zone 524 information has reached all slave servers, and TTLsig is the TTL of 525 the RRSIG records. 527 (It should be noted that an upper limit on the retire interval is 528 given by: 530 Iret = Lsig + Dskw 532 where Lsig is the lifetime of a signature (i.e. the interval between 533 the time the signature was created and the signature end time), and 534 Dskw is the clock skew - the maximum difference in time between the 535 server and a validating resolver. The reasoning here is that 536 whatever happens, a key only has to be available while any signatures 537 created with it are valid. Wherever a signature record is held - 538 published in the zone and/or held in a resolver cache - it won't be 539 valid for longer than Lsig after it was created. The Dskw term is 540 present to account for the fact that the signature end time is an 541 absolute time rather than interval, and systems may not agree exactly 542 about the time.) 544 The time at which all RRSIG records created with this key have 545 expired from resolver caches is the dead time (Tdea), given by: 547 Tdea = Tret + Iret 549 ...at which point the key is said to be dead. 551 Event 9: at any time after the key becomes dead, it can be removed 552 from the zone and the DNSKEY RRset re-signed with the current key- 553 signing key. This time is the removal time (Trem), given by: 555 Trem >= Tdea 557 ...at which time the key is said to be removed. 559 3.2.2. Double-Signature Method 561 In the Double-Signature method, both the new key and signatures 562 created using it are introduced at the same time. After a period 563 during which this information propagates to validating resolver 564 caches, the old key and signature are removed. The time line for the 565 method is shown below: 567 |1| |2| |3| |4| |5| |6| 568 | | | | | | 569 Key N | |<-------Lzsk------>|<-----Iret----->| | 570 | | | | | | 571 Key N+1 | | | |<----------Lzsk------- - - 572 | | | | | | 573 Tgen Tact Tret Tdea Trem 575 ---- Time ----> 577 Figure 2: Timeline for a Double-Signature ZSK rollover. 579 Event 1: key N is generated at the generate time (Tgen). Although 580 there is no reason why the key cannot be generated immediately prior 581 to publication in the zone (Event 2), some implementations may find 582 it convenient to create a pool of keys in one operation and draw from 583 that pool as required. For this reason, it is shown as a separate 584 event. Keys that are available for use but not published are said to 585 be generated. 587 Event 2: key N is added to the DNSKEY RRset and is immediately used 588 to sign the zone; existing signatures in the zone are not removed. 589 This is the active time (Tact) and the key is said to be active. 591 Event 3: at some time later, the predecessor key (key N-1) and its 592 signatures can be withdrawn from the zone. (The timing of key 593 removal is discussed further in the description of event 5.) 595 Event 4: the successor key (key N+1) is introduced into the zone and 596 starts being used to sign RRsets. The successor is key is now active 597 and the current key (key N) is said to be retired. This time is the 598 retire time of the key (Tret); it is also the active time of the 599 successor key (TactS). 601 Tret = Tact + Lzsk 603 Event 5: before key N can be withdrawn from the zone, all RRsets that 604 need to be signed must have been signed by the successor key (as a 605 result, all these RRsets are now signed twice, once by key N and once 606 by its successor) and the information must have reached all 607 validating resolvers that may have RRsets from this zone cached. 609 This takes Iret, the retire interval, given by the expression: 611 Iret = Dsgn + Dprp + max(TTLkey, TTLsig) 613 As before, Dsgn is the time taken to sign the zone with the new key 614 and Dprp is the propagation delay. The final term is the period to 615 wait for old key and signature data to expire from caches. After the 616 end of this interval, key N is said to be dead. This occurs at the 617 dead time (Tdea) so: 619 Tdea = Tret + Iret 621 Event 6: at some later time key N and its signatures can be removed 622 from the zone. This is the removal time Trem, given by: 624 Trem >= Tdea 626 3.2.3. Double-RRSIG Method 628 As noted above, "Double-Signature" is simultaneous rollover of both 629 signature and key. The time line for a pure Double-Signature ZSK 630 rollover (the Double-RRSIG method) - where new signatures are 631 introduced, the key changed, and finally the old signatures removed - 632 is shown below: 634 |1||2| |3| |4||5| |6||7| |8||9| |10| |11| 635 | | | | | | | | | | | 636 Key N | |<-Dsgn->| | |<-----------Lzsk-------->|<-Iret->| | 637 | |<---IpubG-->| |<-IpubK->| | | | | | 638 | | | | | | | | | | | 639 Key N+1 | | | | | | |<-IpubG->| | | | 640 | | | | | | | | | | | 641 Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem 643 ---- Time ----> 645 Figure 3: Timeline for a Double-Signature ZSK rollover. 647 Event 1: key N is generated at the generate time (Tgen). Although 648 there is no reason why the key cannot be generated immediately prior 649 to publication in the zone (Event 2), some implementations may find 650 it convenient to create a pool of keys in one operation and draw from 651 that pool as required. For this reason, it is shown as a separate 652 event. Keys that are available for use but not published are said to 653 be generated. 655 Event 2: key N is used to sign the zone but existing signatures are 656 retained. Although the new ZSK is not published in the zone at this 657 point, for analogy with the other ZSK rollover methods and because 658 this is the first time that key information is visible (albeit 659 indirectly through the created signatures) this time is called the 660 publish time (Tpub). 662 Event 3: after the signing interval, Dsgn, all RRsets that need to be 663 signed have been signed by the new key. (As a result, all these 664 RRsets are now signed twice, once by the existing key and once by the 665 (still-absent) key N. 667 Event 4: there is now a delay while the this information reaches all 668 validating resolvers that may have RRsets from the zone cached. This 669 interval is given by the expression: 671 Dprp + TTLsig 673 ...comprising the delay for the information to propagate through the 674 nameserver infrastructure plus the time taken for signature 675 information to expire from caches. 677 Again in analogy with other key rollover methods, this is defined as 678 key N's ready time (Trdy) and the key is said to be in the ready 679 state. (Although the key is not in the zone, it is ready to be 680 used.) The interval between the publication and ready times is the 681 publication interval of the signature, IpubG, i.e. 683 Trdy = Tpub + IpubG 685 where 687 IpubG = Dsgn + Dprp + TTLsig 689 Event 5: at some later time the predecessor key is removed and the 690 key N added to the DNSKEY RRset. As all the RRs have signatures 691 created by the old and new keys, the records can still be 692 authenticated. This time is the active time (Tact) and the key is 693 now said to be active. 695 Event 6: After IpubK - the publication interval of the key - the 696 newly added DNSKEY RRset has propagated through to all validating 697 resolvers. At this point the old signatures can be removed from the 698 zone. IpubK is given by: 700 IpubK = Dprp + TTLkey 702 Event 7: as before, at some later time thought must be given to 703 rolling the key. The first step is to publish signatures created by 704 the successor key (key N+1) early enough so that key N can be 705 replaced after it has been active for its scheduled lifetime. This 706 occurs at TpubS (the publication time of the successor), given by: 708 TpubS <= Tact + Lzsk - IpubG 710 Event 8: the signatures have propagated through the zone and the new 711 key could be added to the zone. This time is the ready time of the 712 successor (TrdyS). 714 TrdyS = TpubS + IpubG 716 ... where IpubG is as defined above. 718 Event 9: at some later time key N is removed from the zone and the 719 successor key added. This is the retire time of the key (Tret). 721 Event 10: The signatures must remain in the zone for long enough that 722 the new DNSKEY RRset has had enough time to propagate to all caches. 723 Once caches contain the new DNSKEY, the old signatures are no longer 724 of use and can be considered to be dead. The time at which this 725 occurs is the dead time (Tdea), given by: 727 Tdea = Tret + Iret 729 ... where Iret is the retire interval, given by: 731 Iret = IpubK 733 Event 11: At some later time the signatures can be removed from the 734 zone. Although the key has is not longer in the zone, this is 735 information associated with it and so the time can be regarded as the 736 key's remove time (Trem), given by: 738 Trem >= Tdea 740 3.3. Key-Signing Key Rollover Timelines 742 3.3.1. Double-Signature Method 744 The Double-Signature method (also knows as the double-DNSKEY method) 745 involves introducing the new KSK to the zone and waiting until its 746 presence has been registered by all validating resolvers. At this 747 point, the DS record in the parent is changed. Once that change has 748 propagated to all validating resolvers, the old KSK is removed. 750 The timing diagram for such a rollover is: 752 |1| |2| |3| |4| |5| |6| 753 | | | | | | 754 Key N | |<-Ipub->|<--->|<-Dreg->|<---------Lksk--- - - 755 | | | | | | 756 Key N+1 | | | | | | 757 | | | | | | 758 Tgen Tpub Trdy Tsub Tact 760 ---- Time ----> 762 (continued...) 764 |7| |8| |9| |10| |11| |12| 765 | | | | | | 766 Key N - - -------------Lksk------->|<-Iret->| | 767 | | | | | | 768 Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - 769 | | | | | | 770 TpubS TrdyS TsubS Tret Tdea Trem 772 ---- Time (cont) ----> 774 Figure 4: Timeline for a Double-Signature KSK rollover. 776 Event 1: key N is generated at time Tgen. As before, although there 777 is no reason why the key cannot be generated immediately prior to 778 publication, some implementations may find it convenient to create a 779 central pool of keys and draw from it. For this reason, it is again 780 shown as a separate event. 782 Event 2: key N is introduced into the zone; it is added to the DNSKEY 783 RRset, which is then signed by key N and all currently active KSKs. 784 (So at this point, the DNSKEY RRset is signed by both key N and its 785 predecessor KSK. If other KSKs were active, it is signed by these as 786 well.) This is the publication time (Tpub); after this the key is 787 said to be published. 789 Event 3: before it can be used, the key must be published for long 790 enough to guarantee that any validating resolver that has a copy of 791 the DNSKEY RRset from the zone in its cache will have a copy of the 792 RRset that includes this key: in other words, that any prior cached 793 information about the DNSKEY RRset has expired. 795 The interval is the publication interval (Ipub) and, for the second 796 or subsequent KSKs in the zone, is given by: 798 Ipub = Dprp + TTLkey 800 ... where Dprp is the propagation delay for the zone and TTLkey the 801 TTL for the DNSKEY RRset. The time at which this occurs is the key's 802 ready time, Trdy, given by: 804 Trdy = Tpub + Ipub 806 Event 4: at some later time, the DS RR corresponding to the new KSK 807 is submitted to the parent zone for publication. This time is the 808 submission time, Tsub. 810 Event 5: the DS record is published in the parent zone. As this is 811 the point at which all information for authentication - both DNSKEY 812 and DS record - is available in the two zones, it is the active time 813 of the key: 815 Tact = Tsub + Dreg 817 ... where Dreg is the registration delay, the time taken after the DS 818 record has been received by the parent zone manager for it to be 819 placed in the zone. (Parent zones are often managed by different 820 entities, and this term accounts of the organisational overhead of 821 transferring a record.) 823 Event 6: at some time later, all validating resolvers that have the 824 DS RRset cached will have a copy that includes the new DS record. 825 For the second or subsequent DS records, this interval is given by 826 the expression: 828 DprpP + TTLds 830 ... where DprpP is the propagation delay in the parent zone and TTLds 831 the TTL assigned to DS records in that zone. 833 In the case of the first DS record for the zone in question, the 834 expression is slightly different because it is not information about 835 a DS RRset that may be cached, it is information about its absence. 836 In this case, the interval is: 838 DprpP + IngcP 840 where IngcP is the negative cache interval from the zone's SOA 841 record, calculated according to [RFC2308] as the minimum of the TTL 842 of the parent SOA record itself (TTLsoaP), and the "minimum" field in 843 the record's parameters (SOAminP), i.e. 845 IngcP = min(TTLsoaP, SOAminP) 847 Event 7: while key N is active, thought needs to be given to its 848 successor (key N+1). At some time before the scheduled end of the 849 KSK lifetime, the successor KSK is introduced into the zone and is 850 used to sign the DNSKEY RRset. (As before, this means that the 851 DNSKEY RRset is signed by both the current and successor KSK.) This 852 is the publication time of the successor key, TpubS. 854 Event 8: after an interval Ipub, the successor key becomes ready (in 855 that all validating resolvers that have a copy of the DNSKEY RRset 856 have a copy of this key). This is the successor ready time, TrdyS. 858 Event 9: at the successor submission time (TsubS), the DS record 859 corresponding to the successor key is submitted to the parent zone. 861 Event 10: the successor DS record is published in the parent zone and 862 the current DS record withdrawn. The current key is said to be 863 retired and the time at which this occurs is Tret, given by: 865 The relationships between these times are: 867 TpubS <= Tact + Lksk - Dreg - Ipub 869 Tret = Tact + Lksk 871 ... where Lksk is the scheduled lifetime of the KSK. 873 Event 11: key N must remain in the zone until any validators that 874 have the DS RRset cached have a copy of the DS RRset containing the 875 new DS record. This interval is the retire interval, given by: 877 Iret = DprpP + TTLds 879 ... where DprpP is the propagation delay in the parent zone and TTLds 880 the TTL of a DS record. 882 As the key is no longer used for anything, it can also be said to be 883 dead, in which case: 885 Tdea = Tret + Iret 887 Event 12: at some later time, key N is removed from the zone (at the 888 remove time Trem); the key is now said to be removed. 890 Trem >= Tdea 892 3.3.2. Double-DS Method 894 The Double-DS method is the reverse of the Double-Signature method is 895 that it is the DS record that is pre-published (in the parent), and 896 not the DNSKEY. 898 The timeline for the key rollover is shown below: 900 |1| |2| |3| |4| |5| |6| 901 | | | | | | 902 Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - 903 | | | | | | 904 Key N+1 | | | | |<---->|<--Dreg+IpubP- - - 905 | | | | | | 906 Tgen Tsub Tpub Trdy Tact TsubS 908 ---- Time ----> 910 (continued...) 912 |7| |8| |9| |10| 913 | | | | 914 Key N - - -----Lksk---------->|<-Iret->| | 915 | | | | 916 Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - 917 | | | | 918 TrdyS Tret Tdea Trem 920 ---- Time ----> 922 Figure 5: Timeline for a Double-DS KSK rollover. 924 Event 1: key N is generated at time Tgen. As before, although there 925 is no reason why the key cannot be generated immediately prior to 926 publication, some implementations may find it convenient to create a 927 central pool of keys and draw from it. For this reason, it is again 928 shown as a separate event. 930 Event 2: the DS record corresponding to key N is submitted for 931 publication in the parent zone. This time is the submission time 932 (Tsub). 934 Event 3: after the registration delay, Dreg, the DS record is 935 published in the parent zone. This is the publication time Tpub, 936 given by: 938 Tpub = Tsub + Dreg 940 Event 4: at some later time, any validating resolver that has copies 941 of the DS RRset in its cache will have a copy of the DS record for 942 key N. At this point, key N, if introduced into the DNSKEY RRset, 943 could be used to validate the zone. For this reason, this time is 944 known as the key's ready time, Trdy, and is given by: 946 Trdy = Tpub + IpubP 948 IpubP is the parent publication interval and is given by the 949 expression: 951 IpubP = DprpP + TTLds 953 ... where DprpP is the propagation delay in the parent zone and TTLds 954 the TTL assigned to DS records in that zone. 956 Event 5: at some later time, the key rollover takes place. The 957 predecessor key is withdrawn from the DNSKEY RRset and the new key 958 (key N) introduced and used to sign the RRset. 960 As both DS records have been in the parent zone long enough to ensure 961 that they are in the cache of any validating resolvers that have the 962 DS RRset cached, the zone can be authenticated throughout the 963 rollover - either the resolver has a copy of the DNSKEY RRset (and 964 associated RRSIGs) authenticated by the predecessor key, or it has a 965 copy of the updated RRset authenticated with the new key. 967 This time is the key's active time (Tact) and at this point the key 968 is said to be active. 970 Event 6: at some point thought must be given to key replacement. The 971 DS record for the successor key must be submitted to the parent zone 972 at a time such that when the current key is withdrawn, any validating 973 resolver that has DS records in its cache will have data about the DS 974 record of the successor key. The time at which this occurs is the 975 submission time of the successor, given by: 977 TsubS <= Tact + Lksk - IpubP - Dreg 979 ... where Lksk is the lifetime of the KSK. 981 Event 7: the successor key (key N+1) enters the ready state i.e. its 982 DS record is now in the caches of all validating resolvers that have 983 the parent DS RRset cached. (This is the ready time of the 984 successor, TrdyS.) 986 Event 8: when the current key has been active for its lifetime 987 (Lksk), the current key is removed from the DNSKEY RRset and the 988 successor key added; the RRset is then signed with the successor key. 989 This point is the retire time of the key, Tret, given by: 991 Tret = Tact + Lksk 993 Event 9: at some later time, all copies of the old DNSKEY RRset have 994 expired from caches and the old DS record is no longer needed. This 995 is called the dead time, Tdea, and is given by: 997 Tdea = Tret + Iret 999 ... where Iret is the retire interval, given by: 1001 Iret = Dprp + TTLkey 1003 As before, this term includes the time taken to propagate the RRset 1004 change through the master-slave hierarchy and the time take for the 1005 DNSKEY RRset to expire from caches. 1007 Event 10: at some later time, the DS record is removed from the 1008 parent zone. This is the removal time (Trem), given by: 1010 Trem >= Tdea 1012 3.3.3. Double-RRset Method 1014 In the Double-RRset method, both the DS and DNSKEY records are 1015 changed at the same time, so for a period the zone can be 1016 authenticated with either key. The advantage of this method is its 1017 applicability in cases where zone management policy requires overlap 1018 of authentication keys during a roll. 1020 The timeline for this rollover is shown below: 1022 |1| |2| |3| |4| |5| |6| |7| 1023 | | | | | | | 1024 Key N | |<-Dreg->|<-----Lksk----->|<-Iret->| | 1025 | | | | | | | 1026 Key N+1 | | | |<-Dreg->|<-----Lksk-- - - 1027 | | | | | | | 1028 Tgen Tpub Tact TpubS Tret Tdea Trem 1030 ---- Time ----> 1032 Figure 6: Timeline for a Double-RRset KSK rollover. 1034 Event 1: key N is created at time Tgen and thereby immediately 1035 becomes generated. As before, although there is no reason why the 1036 key cannot be generated immediately prior to publication, some 1037 implementations may find it convenient to create a central pool of 1038 keys and draw from it. For this reason, it is again shown as a 1039 separate event. 1041 Event 2: the key is added to and used for signing the DNSKEY RRset 1042 and is thereby published in the zone. At the same time the 1043 corresponding DS record is submitted to the parent zone for 1044 publication. This time is the publish time (Tpub) and the key is now 1045 said to be published. 1047 Event 3: after Dreg, the registration delay, the DS record is 1048 published in the parent zone. At this point, the zones have all the 1049 information needed for a validating resolver to authenticate the 1050 zone, although the information may not yet have reached all 1051 validating resolver caches. This time is the active time (Tact) and 1052 the key is said to be active. 1054 Tact = Tpub + Dreg 1056 Event 4: at some point we need to give thought to key replacement. 1057 The successor key must be introduced into the zone (and its DS record 1058 submitted to the parent) at a time such that it becomes active when 1059 the current key has been active for its lifetime, Lksk. This time is 1060 TpubS, the publication time of the successor key, and is given by: 1062 TpubS <= Tact + Lksk - Dreg 1064 ... where Lksk is the lifetime of the KSK. 1066 Event 5: the successor key's DS record appears in the parent zone and 1067 the successor key becomes active. At this point, the current key 1068 becomes retired. This occurs at Tret, given by: 1070 Tret = Tact + Lksk 1072 Event 6: the current DNSKEY and DS record must be retained in the 1073 zones until any any validating resolver that has cached the DNSKEY 1074 and/or DS RRsets will have a copy of the data for the successor key. 1075 At this point the current key information is dead, as any validating 1076 resolver can perform authentication using the successor key. This is 1077 the dead time, Tdea, given by: 1079 Tdea = Tret + Iret 1081 ... where Iret is the retire interval. This depends on how long both 1082 the successor DNSKEY and DS records take to propagate through the 1083 nameserver infrastructure and thence into validator caches. These 1084 delays are the publication intervals of the child and parent zones 1085 respectively, so a suitable expression for Iret is: 1087 Iret = max(IpubP, IpubC) 1089 IpubC is the publication interval of the DNSKEY in the child zone, 1090 IpubP that of the DS record in the parent. 1092 The child term comprises two parts - the time taken for the 1093 introduction of the DNSKEY record to be propagated to the downstream 1094 secondary servers (= DprpC, the child propagation delay) and the time 1095 taken for information about the DNSKEY RRset to expire from the 1096 validating resolver cache, i.e. 1098 IpubC = DprpC + TTLkey 1100 TTLkey is the TTL for a DNSKEY record in the child zone. The parent 1101 term is similar: 1103 IpubP = DprpP + TTLds 1105 DprpP the propagation delay in the parent zone and TTLds the TTL for 1106 a DS record in the parent zone. 1108 Event 7: at some later time, the DNSKEY record can be removed from 1109 the child zone and a request can be made to remove the DS record from 1110 the parent zone. This is the removal time, Trem and is given by: 1112 Trem >= Tdea 1114 3.3.4. Interaction with Configured Trust Anchors 1116 Although the preceding sections have been concerned with rolling KSKs 1117 where the trust anchor is a DS record in the parent zone, zone 1118 managers may want to take account of the possibility that some 1119 validating resolvers may have configured trust anchors directly. 1121 Rolling a configured trust anchor is dealt with in [RFC5011]. It 1122 requires introducing the KSK to be used as the trust anchor into the 1123 zone for a period of time before use, and retaining it (with the 1124 "revoke" bit set) for some time after use. The Double-Signature and 1125 Double-RRset methods can be adapted to include [RFC5011] 1126 recommendations so that the rollover will also be signalled to 1127 validating resolvers with configured trust anchors. (The 1128 recommendations are not suitable for the Double-DS method. 1129 Introducing the new key early and retaining the old key after use 1130 effectively converts it into a form of Double-RRset.) 1132 3.3.4.1. Addition of KSK 1134 When the new key is introduced, the publication interval (Ipub) in 1135 the Double-Signature method should also be subject to the condition: 1137 Ipub >= max(30 days, TTLkey) 1139 ... where the right had side of the expression is the add hold-down 1140 time defined in section 2.4.1 of [RFC5011]. 1142 In the Double-RRSIG method, the key should not be regarded as being 1143 active until the add hold-down time has passed. In other words, the 1144 following condition should be enforced: 1146 Tact >= Tpub + max(30 days, TTLkey) 1148 (Effectively, this means extending the lifetime of the key by an 1149 appropriate amount.) 1151 3.3.4.2. Removal of KSK 1153 The timeline for the removal of the key in both methods is modified 1154 by introducing a new state, "revoked". When the key reaches the end 1155 of the retire period, instead of being declared "dead", it is 1156 revoked; the "revoke" bit is set on the DNSKEY RR and is published in 1157 (and used to sign) the DNSKEY RRset. The key is maintained in this 1158 state for the "revoke" interval, Irev, given by: 1160 Irev >= 30 days 1162 ... 30 days being the [RFC5011] remove hold-down time. After this 1163 time, the key is dead and can be removed from the zone when 1164 convenient. 1166 3.3.5. Introduction of First KSK 1168 There is an additional consideration when introducing a KSK into a 1169 zone for the first time, and that is that no validating resolver 1170 should be in a position where it can access the trust anchor before 1171 the KSK appears in the zone. To do so will cause the validating 1172 resolver to declare the zone to be bogus. 1174 This is important: in the case of a secure parent, it means ensuring 1175 that the DS record is not published in the parent zone until there is 1176 no possibility that a validating resolver can obtain the record yet 1177 not be able to obtain the corresponding DNSKEY. In the case of an 1178 insecure parent, i.e. the initial creation of a new security apex, it 1179 is important to not configure trust anchors in validating resolvers 1180 until the DNSKEY RRset has had sufficient time to propagate. In both 1181 cases, this time is the trust anchor availability time (Ttaa) given 1182 by: 1184 Ttaa >= Tpub + IpubC 1186 where 1188 IpubC = DprpC + TTLkeyC 1190 or 1192 IpubC = DprpC + IngcC 1194 The first expression applies if there was previously a DNSKEY RRset 1195 in the child zone, the expression for IpubC including the TTLkeyC 1196 term to account for the time taken for that RRset to expire from 1197 caches. (It is possible that the zone was signed but that the trust 1198 anchor had not been submitted to the parent.) 1200 If the introduction of the KSK caused the appearance of the first 1201 DNSKEY RRset in the child zone, the second expression applies in 1202 which the TTLkeyC term is replaced by Ingc to allow for the effect of 1203 negative caching. 1205 As before, IngcC is the negative cache interval from the child zone's 1206 SOA record, calculated according to [RFC2308] as the minimum of the 1207 TTL of the SOA record itself (TTLsoaC), and the "minimum" field in 1208 the record's parameters (SOAminC), i.e. 1210 IngcC = min(TTLsoaC, SOAminC) 1212 4. Standby Keys 1214 Although keys will usually be rolled according to some regular 1215 schedule, there may be occasions when an emergency rollover is 1216 required, e.g. if the active key is suspected of being compromised. 1217 The aim of the emergency rollover is to allow the zone to be re- 1218 signed with a new key as soon as possible. As a key must be in the 1219 ready state to sign the zone, having at least one additional key (a 1220 standby key) in this state at all times will minimise delay. 1222 In the case of a ZSK, a standby key only really makes sense with the 1223 Pre-Publication method. A permanent standby DNSKEY RR should be 1224 included in zone or successor keys could be introduced as soon as 1225 possible after a key becomes active. Either way results in an 1226 additional ZSK in the DNSKEY RRset that can immediately be used to 1227 sign the zone if the current key is compromised. 1229 (Although in theory the mechanism could be used with both the Double- 1230 Signature and Double-RRSIG methods, it would require Pre-Publication 1231 of the signatures. Essentially, the standby key would be permanently 1232 active, as it would have to be periodically used to renew signatures. 1233 Zones would also permanently require two sets of signatures, 1234 something that could have a performance impact in large zones.) 1236 A standby key can also be used with the Double-Signature and 1237 Double-DS methods of rolling a KSK. (The idea of a standby key in 1238 the Double-RRset effectively means having two active keys.) The 1239 Double-Signature method requires that the standby KSK be included in 1240 the DNSKEY RRset; rolling the key then requires just the introduction 1241 of the DS record in the parent. (Note that the DNSKEY should also be 1242 used to sign the DNSKEY RRset. As the RRset and its signatures 1243 travel together, merely adding the DNSKEY does not provide the 1244 desired time saving; to be used in a rollover requires that the 1245 DNSKEY RRset be signed with the standby key, and this introduces a 1246 delay whilst the RRset and its signatures propagate to the caches of 1247 validating resolvers. There is no time advantage over introducing a 1248 new DNSKEY and signing the RRset with it at the same time.) 1250 In the Double-DS method of rolling a KSK, it is not a standby key 1251 that is present, it is a standby DS record in the parent zone. 1252 Whatever algorithm is used, the standby item of data can be 1253 introduced as a permanent standby, or be a successor introduced as 1254 early as possible. 1256 5. Algorithm Considerations 1258 The preceding sections have implicitly assumed that all keys and 1259 signatures are created using a single algorithm. However, [RFC4035] 1260 (section 2.4) states that "There MUST be an RRSIG for each RRset 1261 using at least one DNSKEY of each algorithm in the zone apex DNSKEY 1262 RRset". 1264 Except in the case of an algorithm rollover - where the algorithms 1265 used to create the signatures are being changed - there is no 1266 relationship between the keys of different algorithms. This means 1267 that they can be rolled independently of one another. In other 1268 words, the key rollover logic described above should be run 1269 separately for each algorithm; the union of the results is included 1270 in the zone, which is signed using the active key for each algorithm. 1272 6. Summary 1274 For ZSKs, "Pre-Publication" is generally considered to be the 1275 preferred way of rolling keys. As shown in this document, the time 1276 taken to roll is wholly dependent on parameters under the control of 1277 the zone manager. 1279 In contrast, "Double-RRset" is the most efficient method for KSK 1280 rollover due to the ability to have new DS records and DNSKEY RRsets 1281 propagate in parallel. The time taken to roll KSKs may depend on 1282 factors related to the parent zone if the parent is signed. For 1283 zones that intend to comply with the recommendations of [RFC5011], in 1284 virtually all cases the rollover time will be determined by the 1285 RFC5011 "add hold-down" and "remove hold-down" times. It should be 1286 emphasized that this delay is a policy choice and not a function of 1287 timing values and that it also requires changes to the rollover 1288 process due to the need to manage revocation of trust anchors. 1290 Finally, the treatment of emergency key rollover is significantly 1291 simplified by the introduction of stand-by keys as standard practice 1292 during all types of rollovers. 1294 7. IANA Considerations 1296 This memo includes no request to IANA. 1298 8. Security Considerations 1300 This document does not introduce any new security issues beyond those 1301 already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. 1303 9. Acknowledgements 1305 The authors gratefully acknowledge help and contributions from Roy 1306 Arends and Wouter Wijngaards. 1308 10. Change History 1310 o draft-morris-dnsop-dnssec-key-timing-02 1311 * General restructuring. 1312 * Added descriptions of more rollovers (IETF-76 meeting). 1313 * Improved description of key states and removed diagram. 1314 * Provided simpler description of standby keys. 1315 * Added section concerning first key in a zone. 1316 * Moved [RFC5011] to a separate section. 1317 * Various nits fixed (Alfred Hones, Jeremy Reed, Scott Rose, Sion 1318 Lloyd, Tony FinchX). 1320 o draft-morris-dnsop-dnssec-key-timing-01 1321 * Use latest boilerplate for IPR text. 1322 * List different ways to roll a KSK (acknowledgements to Mark 1323 Andrews). 1324 * Restructure to concentrate on key timing, not management 1325 procedures. 1326 * Change symbol notation (Diane Davidowicz and others). 1327 * Added key state transition diagram (Diane Davidowicz). 1328 * Corrected spelling, formatting, grammatical and style errors 1329 (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya). 1330 * Added note that in the case of multiple algorithms, the 1331 signatures and rollovers for each algorithm can be considered as 1332 more or less independent (Alfred Hoenes). 1333 * Take account of the fact that signing a zone is not atomic 1334 (Chris Thompson). 1335 * Add section contrasting pre-publication rollover with double 1336 signature rollover (Matthijs Mekking). 1337 * Retained distinction between first and subsequent keys in 1338 definition of initial publication interval (Matthijs Mekking). 1340 o draft-morris-dnsop-dnssec-key-timing-00 1341 Initial draft. 1343 11. References 1344 11.1. Normative References 1346 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1347 NCACHE)", RFC 2308, March 1998. 1349 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1350 Rose, "DNS Security Introduction and Requirements", 1351 RFC 4033, March 2005. 1353 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1354 Rose, "Resource Records for the DNS Security Extensions", 1355 RFC 4034, March 2005. 1357 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1358 Rose, "Protocol Modifications for the DNS Security 1359 Extensions", RFC 4035, March 2005. 1361 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1362 Trust Anchors", RFC 5011, September 2007. 1364 11.2. Informative References 1366 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1367 RFC 4641, September 2006. 1369 Appendix A. List of Symbols 1371 The document defines a number of symbols, all of which are listed 1372 here. All are of the form: 1374 All symbols used in the text are of the form: 1376 1378 where: 1380 is an upper-case character indicating what type the symbol is. 1381 Defined types are: 1383 D delay: interval that is a feature of the process 1385 I interval between two events 1387 L lifetime: interval set by the zone manager 1388 SOA parameter related to SOA RR 1390 T a point in time 1392 TTL TTL of a record 1394 T and I are self-explanatory. D, and L are also time periods, but 1395 whereas I values are intervals between two events (even if the events 1396 are defined in terms of the interval, e.g. the dead time occurs 1397 "retire interval" after the retire time), D, and L are fixed 1398 intervals. An "L" interval (lifetime) is chosen by the zone manager 1399 and is a feature of policy. A "D" interval (delay) is a feature of 1400 the process, probably outside control of the zone manager. SOA and 1401 TTL are used just because they are common terms. 1403 is lower-case and defines what object or event the variable is 1404 related to, e.g. 1406 act active 1408 ngc negative cache 1410 pub publication 1412 Finally, is a capital letter that distinguishes between the 1413 same variable applying to different instances of an object and is one 1414 of: 1416 C child 1418 G signature 1420 K key 1422 P parent 1424 S successor 1426 The list of variables used in the text is: 1428 Dprp Propagation delay. The amount of time for a change made at 1429 a master nameserver to propagate to all the slave 1430 nameservers. 1432 DprpC Propagation delay in the child zone. 1434 DprpP Propagation delay in the parent zone. 1436 Dreg Registration delay. As a parent zone is often managed by a 1437 different organisation to that managing the child zone, the 1438 delays associated with passing data between zones is 1439 captured by this term. 1441 Dskw Clock skew. The maximum difference in time between the 1442 signing system and the resolver. 1444 Dsgn Signing delay. After the introduction of a new ZSK, the 1445 amount of time taken for all the RRs in the zone to be 1446 signed with it. 1448 Ingc Negative cache interval. 1450 IngcP Negative cache interval of the child zone. 1452 IngcP Negative cache interval of the parent zone. 1454 Ipub Publication interval. The amount of time that must elapse 1455 after the publication of a key before it can be considered 1456 to have entered the ready state. 1458 IpubC Publication interval in the child zone. 1460 IpubG Publication interval for the signature. 1462 IpubK Publication interval for the key. 1464 IpubP Publication interval in the parent zone. 1466 Iret Retire interval. The amount of time that must elapse after 1467 a key enters the retire state for any signatures created 1468 with it to be purged from validating resolver caches. 1470 Irev Revoke interval. The amount of time that a KSK must remain 1471 published with the revoke bit set to satisfy [RFC5011] 1472 considerations. 1474 Lksk Lifetime of a key-signing key. This is the intended amount 1475 of time for which this particular KSK is regarded as the 1476 active KSK. Depending on when the key is rolled-over, the 1477 actual lifetime may be longer or shorter than this. 1479 Lzsk Lifetime of a zone-signing key. This is the intended 1480 amount of time for which the ZSK is used to sign the zone. 1481 Depending on when the key is rolled-over, the actual 1482 lifetime may be longer or shorter than this. 1484 Lsig Lifetime of a signature: the difference in time between the 1485 signature's expiration time and the time at which the 1486 signature was created. (Note that this is not the 1487 difference between the signature's expiration and inception 1488 times: the latter is usually set a small amount of time 1489 before the signature is created to allow for clock skew 1490 between the signing system and the validating resolver.) 1492 SOAmin Value of the "minimum" field from an SOA record. 1494 SOAminC Value of the "minimum" field from an SOA record in the 1495 child zone. 1497 SOAminP Value of the "minimum" field from an SOA record in the 1498 parent zone. 1500 Tact Active time of the key; the time at which the key is 1501 regarded as the principal key for the zone. 1503 TactS Active time of the successor key. 1505 Tdea Dead time of a key. Applicable only to ZSKs, this is the 1506 time at which any record signatures held in validating 1507 resolver caches are guaranteed to be created with the 1508 successor key. 1510 Tgen Generate time of a key. The time that a key is created. 1512 Tpub Publish time of a key. The time that a key appears in a 1513 zone for the first time. 1515 TpubS Publish time of the successor key. 1517 Trem Removal time of a key. The time at which a key is removed 1518 from the zone. 1520 Tret Retire time of a key. The time at which a successor key 1521 starts being used to sign the zone. 1523 Trdy Ready time of a key. The time at which it can be 1524 guaranteed that validating resolvers that have key 1525 information from this zone cached have a copy of this key 1526 in their cache. (In the case of KSKs, should the 1527 validating resolvers also have DS information from the 1528 parent zone cached, the cache must include information 1529 about the DS record corresponding to the key.) 1531 TrdyS Ready time of a successor key. 1533 Tsub Submit time - the time at which the DS record of a KSK is 1534 submitted to the parent. 1536 TsubS Submit time of the successor key. 1538 TTLds Time to live of a DS record (in the parent zone). 1540 TTLkey Time to live of a DNSKEY record. 1542 TTLkeyC Time to live of a DNSKEY record in the child zone. 1544 TTLsoa Time to live of a SOA record. 1546 TTLsoaC Time to live of a SOA record in the child zone. 1548 TTLsoaP Time to live of a SOA record in the parent zone. 1550 TTLsig Time to live of an RRSIG record. 1552 Ttaa Trust anchor availability time. The time at which a trust 1553 anchor record can be made available when a KSK is first 1554 introduced into a zone. 1556 Authors' Addresses 1558 Stephen Morris 1559 Nominet 1560 Minerva House, Edmund Halley Road 1561 Oxford, OX4 4DQ 1562 UK 1564 Phone: +44 1865 332211 1565 Email: stephen@nominet.org.uk 1566 Johan Ihren 1567 Netnod 1568 Franzengatan 5 1569 Stockholm, SE-112 51 1570 Sweden 1572 Phone: +46 8615 8573 1573 Email: johani@autonomica.se 1575 John Dickinson 1576 Sinodun Internet Technologies Ltd 1577 Stables 4 Suite 11, Howbery Park 1578 Wallingford, Oxfordshire OX10 8BA 1579 UK 1581 Phone: +44 1491 818120 1582 Email: jad@sinodun.com