idnits 2.17.1 draft-ietf-dnsop-dnssec-key-timing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-dnsop-rfc4641bis-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Morris 3 Internet-Draft ISC 4 Intended status: Informational J. Ihren 5 Expires: January 10, 2013 Netnod 6 J. Dickinson 7 Sinodun 8 July 9, 2012 10 DNSSEC Key Timing Considerations 11 draft-ietf-dnsop-dnssec-key-timing-03.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 10, 2013. 37 Copyright Notice 39 Copyright (c) 2012 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 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 66 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 67 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12 68 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13 69 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15 70 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 16 71 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18 72 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21 73 3.3.4. Interaction with Configured Trust Anchors . . . . . . 23 74 3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 24 75 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 26 77 6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26 78 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 82 11. Normative References . . . . . . . . . . . . . . . . . . . . . 27 83 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 28 84 Appendix B. Change History (To be removed on publication) . . . . 31 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 87 1. Introduction 89 1.1. Key Rolling Considerations 91 When a zone is secured with DNSSEC, the zone manager must be prepared 92 to replace ("roll") the keys used in the signing process. The 93 rolling of keys may be caused by compromise of one or more of the 94 existing keys, or it may be due to a management policy that demands 95 periodic key replacement for security or operational reasons. In 96 order to implement a key rollover, the keys need to be introduced 97 into and removed from the zone at the appropriate times. 98 Considerations that must be taken into account are: 100 o DNSKEY records and associated information (such as the associated 101 DS records or RRSIG records created with the key) are not only 102 held at the authoritative nameserver, they are also cached by 103 resolvers. The data on these systems can be interlinked, e.g., a 104 validating resolver may try to validate a signature retrieved from 105 a cache with a key obtained separately. 107 o Zone "boot-strapping" events, where a zone is signed for the first 108 time, can be common in configurations where a large number of 109 zones are being served. Procedures should be able to cope with 110 the introduction of keys into the zone for the first time as well 111 as "steady-state", where the records are being replaced as part of 112 normal zone maintenance. 114 o To allow for an emergency re-signing of the zone as soon as 115 possible after a key compromise has been detected, standby keys 116 (additional keys over and above those used to sign the zone) need 117 to be present. 119 o A query for the DNSKEY RRset returns all DNSKEY records in the 120 zone. As there is limited space in the UDP packet (even with 121 EDNS0 support), key records no longer needed must be periodically 122 removed. (For the same reason, the number of standby keys in the 123 zone should be restricted to the minimum required to support the 124 key management policy.) 126 Management policy, e.g., how long a key is used for, also needs to be 127 considered. However, the point of key management logic is not to 128 ensure that a rollover is completed at a certain time but rather to 129 ensure that no changes are made to the state of keys published in the 130 zone until it is "safe" to do so ("safe" in this context meaning that 131 at no time during the rollover process does any part of the zone ever 132 go bogus). In other words, although key management logic enforces 133 policy, it may not enforce it strictly. 135 A high-level overview of key rollover can be found in 136 [I-D.ietf-dnsop-rfc4641bis]. In contrast, this document focuses on 137 the low-level timing detail of two classes of operations described 138 there, the rollover of key-signing keys, and the rollover of zone 139 signing keys. 141 1.2. Types of Keys 143 Although DNSSEC validation treats all keys equally, [RFC4033] 144 recognises the broad classification of zone-signing keys (ZSK) and 145 key-signing keys (KSK). A ZSK is used to authenticate information 146 within the zone; a KSK is used to authenticate the zone's DNSKEY 147 RRset. The main implication for this distinction concerns the 148 consistency of information during a rollover. 150 During operation, a validating resolver must use separate pieces of 151 information to perform an authentication. At the time of 152 authentication, each piece of information may be in its cache or may 153 need to be retrieved from the authoritative server. The rollover 154 process needs to happen in such a way that at all times during the 155 rollover the information is consistent. With a ZSK, the information 156 is the RRSIG (plus associated RRset) and the DNSKEY. These are both 157 obtained from the same zone. In the case of the KSK, the information 158 is the DNSKEY and DS RRset with the latter being obtained from a 159 different zone. 161 Although there are similarities in the algorithms to roll ZSKs and 162 KSKs, there are a number of differences. For this reason, the two 163 types of rollovers are described separately. It is also possible to 164 use a single key as both the ZSK and KSK. However, the rolling of 165 this type of key is not treated in this document. 167 1.3. Terminology 169 The terminology used in this document is as defined in [RFC4033] and 170 [RFC5011]. 172 A number of symbols are used to identify times, intervals, etc. All 173 are listed in Appendix A. 175 1.4. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 2. Rollover Methods 183 2.1. ZSK Rollovers 185 A ZSK can be rolled in one of three ways: 187 o Pre-Publication: described in [I-D.ietf-dnsop-rfc4641bis], the new 188 key is introduced into the DNSKEY RRset which is then re-signed. 189 This state of affairs remains in place for long enough to ensure 190 that any cached DNSKEY RRsets contain both keys. At that point 191 signatures created with the old key can be replaced by those 192 created with the new key, and the old signatures removed. During 193 the re-signing process (which may or may not be atomic depending 194 on how the zone is managed), it doesn't matter which key an RRSIG 195 record retrieved by a resolver was created with; cached copies of 196 the DNSKEY RRset will contain both the old and new keys. 198 Once the zone contains only signatures created with the new key, 199 there is an interval during which RRSIG records created with the 200 old key expire from caches. After this, there will be no 201 signatures anywhere that were created using the old key, and it 202 can can be removed from the DNSKEY RRset. 204 o Double-Signature: also mentioned in [I-D.ietf-dnsop-rfc4641bis], 205 this involves introducing the new key into the zone and using it 206 to create additional RRSIG records; the old key and existing RRSIG 207 records are retained. During the period in which the zone is 208 being signed (again, the signing process may not be atomic), 209 validating resolvers are always able to validate RRSIGs: any 210 combination of old and new DNSKEY RRset and RRSIG allows at least 211 one signature to be validated. 213 Once the signing process is complete and enough time has elapsed 214 to allow all old information to expire from caches, the old key 215 and signatures can be removed from the zone. As before, during 216 this period any combination of DNSKEY RRset and RRSIG will allow 217 validation of at least one signature. 219 o Double-RRSIG: strictly speaking, the use of the term "Double- 220 Signature" above is a misnomer as the method is not only double 221 signature, it is also double key as well. A true Double-Signature 222 method (here called the Double-RRSIG method) involves introducing 223 new signatures in the zone (while still retaining the old ones) 224 but not introducing the new key. 226 Once the signing process is complete and enough time has elapsed 227 to ensure that all caches that may contain an RR and associated 228 RRSIG have a copy of both signatures, the key is changed. After a 229 further interval during which the old DNSKEY RRset expires from 230 caches, the old signatures are removed from the zone. 232 Of three methods, Double-Signature is conceptually the simplest - 233 introduce the new key and new signatures, then approximately one TTL 234 later remove the old key and old signatures. Pre-Publication is more 235 complex - introduce the new key, approximately one TTL later sign the 236 records, and approximately one TTL after that remove the old key. 237 Double-RRSIG is essentially the reverse of Pre-Publication - 238 introduce the new signatures, approximately one TTL later change the 239 key, and approximately one TTL after that remove the old signatures. 241 2.2. KSK Rollovers 243 For ZSKs, the issue for the validating resolver is to ensure that it 244 has access to the ZSK that corresponds to a particular signature. In 245 the KSK case, this can never be a problem as the KSK is only used for 246 one signature (that over the DNSKEY RRset) and both the key and the 247 signature travel together. Instead, the issue is to ensure that the 248 KSK is trusted. 250 Trust in the KSK is either due to the existence of a signed and 251 validated DS record in the parent zone or an explicitly configured 252 trust anchor. If the former, the rollover algorithm will need to 253 involve the parent zone in the addition and removal of DS records, so 254 timings are not wholly under the control of the zone manager. If the 255 latter, [RFC5011] timings will be needed to roll the keys. (Even in 256 the case where authentication is via a DS record, the zone manager 257 may elect to include [RFC5011] timings in the key rolling process so 258 as to cope with the possibility that the key has also been explicitly 259 configured as a trust anchor.) 261 It is important to note that this does not preclude the development 262 of key rollover logic; in accordance with the goal of the rollover 263 logic being able to determine when a state change is "safe", the only 264 effect of being dependent on the parent is that there may be a period 265 of waiting for the parent to respond in addition to any delay the key 266 rollover logic requires. Although this introduces additional delays, 267 even with a parent that is less than ideally responsive the only 268 effect will be a slowdown in the rollover state transitions. This 269 may cause a policy violation, but will not cause any operational 270 problems. 272 Like the ZSK case, there are three methods for rolling a KSK: 274 o Double-Signature: also known as Double-DNSKEY, the new KSK is 275 added to the DNSKEY RRset which is then signed with both the old 276 and new key. After waiting for the old RRset to expire from 277 caches, the DS record in the parent zone is changed. After 278 waiting a further interval for this change to be reflected in 279 caches, the old key is removed from the RRset. (The name "Double- 280 Signature" is used because, like the ZSK method of the same name, 281 the new key is introduced and immediately used for signing.) 283 o Double-DS: the new DS record is published. After waiting for this 284 change to propagate into caches, the KSK is changed. After a 285 further interval during which the old DNSKEY RRset expires from 286 caches, the old DS record is removed. 288 o Double-RRset: the new KSK is added to the DNSKEY RRset which is 289 then signed with both the old and new key, and the new DS record 290 added to the parent zone. After waiting a suitable interval for 291 the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY 292 and DS record are removed. 294 In essence, "Double-Signature" means that the new KSK is introduced 295 first and used to sign the DNSKEY RRset. The DS record is changed, 296 and finally the old KSK removed. With "Double-DS" it is the other 297 way around. Finally, Double-RRset does both updates more or less in 298 parallel. 300 2.3. Summary 302 The methods can be summarised as follows: 304 +------------------+------------------+-----------------------------+ 305 | ZSK Method | KSK Method | Description | 306 +------------------+------------------+-----------------------------+ 307 | Pre-Publication | (not applicable) | Publish the DNSKEY before | 308 | | | the RRSIGs. | 309 | Double-Signature | Double-Signature | Publish the DNSKEY and | 310 | | | RRSIGs at same time. For a | 311 | | | KSK, this happens before | 312 | | | the DS is published. | 313 | Double-RRSIG | (not applicable) | Publish RRSIGs before the | 314 | | | DNSKEY. | 315 | (not applicable) | Double-DS | Publish DS before the | 316 | | | DNSKEY. | 317 | (not applicable) | Double-RRset | Publish DNSKEY and DS in | 318 | | | parallel. | 319 +------------------+------------------+-----------------------------+ 321 Table 1 323 3. Key Rollover Timelines 325 3.1. Key States 327 During the rolling process, a key moves through different states. 328 The defined states are: 330 Generated The key has been created, but has not yet been used for 331 anything. 333 Published The DNSKEY record - or information associated with it - 334 is published in the zone, but predecessors of the key (or 335 associated information) may be held in caches. 337 The idea of "associated information" is used in rollover 338 methods where RRSIG or DS records are published first and 339 the DNSKEY is changed in an atomic operation. It allows 340 the rollover still to be thought of as moving through a 341 set of states. In the rest of this section, the term 342 "key data" should be taken to mean "key or associated 343 information". 345 Ready The new key data has been published for long enough to 346 guarantee that any previous versions of the DNSKEY RRset 347 have expired from caches. 349 Active The key has started to be used to sign RRsets. Note that 350 when this state is entered, it may not be possible for 351 validating resolvers to use the key for validation in all 352 cases: the zone signing may not have finished, or the 353 data might not have reached the resolver because of 354 propagation delays and/or caching issues. If this is the 355 case, the resolver will have to rely on the key's 356 predecessor instead. 358 Retired A successor key has become active and this key is no 359 longer being used to generate RRSIGs. However, as there 360 may still be RRSIGs in caches that were generated using 361 this key, it is being retained in the zone until they 362 have expired. 364 Dead The key is published in the zone but there is no longer 365 information anywhere that requires its presence. Hence 366 the key can be removed from the zone at any time. 368 Removed The key has been removed from the zone. 370 There is one additional state, used where [RFC5011] considerations 371 are in effect (see Section 3.3.4): 373 Revoked The key is published for a period with the "revoke" bit 374 set as a way of notifying validating resolvers that have 375 configured it as an [RFC5011] trust anchor that it is 376 about to be removed from the zone. 378 3.2. Zone-Signing Key Timelines 380 The following sections describe the rolling of a ZSK. They show the 381 events in the lifetime of a key (referred to as "key N") and cover 382 its replacement by its successor (key N+1). 384 3.2.1. Pre-Publication Method 386 The following diagram shows the timeline of a Pre-Publication 387 rollover. Time increases along the horizontal scale from left to 388 right and the vertical lines indicate events in the process. 389 Significant times and time intervals are marked. 391 |1| |2| |3| |4| |5| |6| |7| |8| |9| 392 | | | | | | | | | 393 Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| 394 | | | | | | | | | 395 Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - 396 | | | | | | | | | 397 Tgen Tpub Trdy Tact TpubS Tret Tdea Trem 399 ---- Time ----> 401 Figure 1: Timeline for a Pre-Publication ZSK rollover. 403 Event 1: Key N is generated at the generate time (Tgen). Although 404 there is no reason why the key cannot be generated immediately prior 405 to its publication in the zone (Event 2), some implementations may 406 find it convenient to create a pool of keys in one operation and draw 407 from that pool as required. For this reason, it is shown as a 408 separate event. Keys that are available for use but not published 409 are said to be generated. 411 Event 2: Key N's DNSKEY record is put into the zone, i.e., it is 412 added to the DNSKEY RRset which is then re-signed with the current 413 key-signing key. The time at which this occurs is the key's 414 publication time (Tpub), and the key is now said to be published. 415 Note that the key is not yet used to sign records. 417 Event 3: Before it can be used, the key must be published for long 418 enough to guarantee that any cached version of the zone's DNSKEY 419 RRset includes this key. 421 This interval is the publication interval (Ipub) and, for the second 422 or subsequent keys in the zone, is given by: 424 Ipub = Dprp + TTLkey 426 Here, Dprp is the propagation delay - the time taken in the worst- 427 case situation for a change introduced at the master to replicate to 428 all slave servers - which depends on the depth of the master-slave 429 hierarchy. TTLkey is the time-to-live (TTL) for the DNSKEY records 430 in the zone. The sum is therefore the maximum time taken for 431 existing DNSKEY records to expire from caches, regardless of the 432 nameserver from which they were retrieved. 434 (The case of introducing the first ZSK into the zone is discussed in 435 Section 3.3.5.) 437 After a delay of Ipub, the key is said to be ready and could be used 438 to sign records. The time at which this event occurs is the key's 439 ready time (Trdy), which is given by: 441 Trdy = Tpub + Ipub 443 Event 4: At some later time, the key starts being used to sign 444 RRsets. This point is the activation time (Tact) and after this, the 445 key is said to be active. 447 Event 5: At some point thought must be given to its successor (key 448 N+1). As with the introduction of the currently active key into the 449 zone, the successor key will need to be published at least Ipub 450 before it is activated. Denoting the publication time of the 451 successor key by TpubS, then: 453 TpubS <= Tact + Lzsk - Ipub 455 Here, Lzsk is the length of time for which a ZSK will be used (the 456 ZSK lifetime). It should be noted that unlike the publication 457 interval, Lzsk is not determined by timing logic, but by key 458 management policy. Lzsk will be set by the operator according to 459 their assessment of the risks posed by continuing to use a key and 460 the risks associated with key rollover. However, operational 461 considerations may mean a key is active for slightly more or less 462 than Lzsk. 464 Event 6: While key N is still active, its successor becomes ready. 465 From this time onwards, key N+1 could be used to sign the zone. 467 Event 7: When key N has been in use for an interval equal to the ZSK 468 lifetime, it is retired (i.e., it will never again be used to 469 generate new signatures) and key N+1 activated and used to sign the 470 zone. This is the retire time of key N (Tret) and is given by: 472 Tret = Tact + Lzsk 474 It is also the activation time of the successor key (TactS). Note 475 that operational considerations may cause key N to remain in use for 476 longer than Lzsk; if so, the retirement actually occurs when the 477 successor key is made active. 479 Event 8: The retired key needs to be retained in the zone whilst any 480 RRSIG records created using this key are still published in the zone 481 or held in caches. (It is possible that a validating resolver could 482 have an unexpired RRSIG record and an expired DNSKEY RRset in the 483 cache when it is asked to provide both to a client. In this case the 484 DNSKEY RRset would need to be looked up again.) This means that once 485 the key is no longer used to sign records, it should be retained in 486 the zone for at least the retire interval (Iret) given by: 488 Iret = Dsgn + Dprp + TTLsig 490 Dsgn is the delay needed to ensure that all existing RRsets have been 491 re-signed with the new key. Dprp is (as described above) the 492 propagation delay, required to guarantee that the updated zone 493 information has reached all slave servers, and TTLsig is the maximum 494 TTL of all the RRSIG records in the zone created with the ZSK. 496 The time at which all RRSIG records created with this key have 497 expired from resolver caches is the dead time (Tdea), given by: 499 Tdea = Tret + Iret 501 ... at which point the key is said to be dead. 503 Event 9: At any time after the key becomes dead, it can be removed 504 from the zone's DNSKEY RRset, which must then be re-signed with the 505 current key-signing key. This time is the removal time (Trem), given 506 by: 508 Trem >= Tdea 510 ... at which time the key is said to be removed. 512 3.2.2. Double-Signature Method 514 The timeline for a double-signature rollover is shown below. The 515 diagram follows the convention described in Section 3.2.1 517 |1| |2| |3| |4| |5| 518 | | | | | 519 Key N | |<----Lzsk--->|<---Iret--->| | 520 | | | | | 521 Key N+1 | | |<-----Lzsk------- - - 522 | | | | | 523 Tgen Tact Tret Tdea Trem 525 ---- Time ----> 527 Figure 2: Timeline for a Double-Signature ZSK rollover. 529 Event 1: Key N is generated at the generate time (Tgen). Although 530 there is no reason why the key cannot be generated immediately prior 531 to its publication in the zone (Event 2), some implementations may 532 find it convenient to create a pool of keys in one operation and draw 533 from that pool as required. For this reason, it is shown as a 534 separate event. Keys that are available for use but not published 535 are said to be generated. 537 Event 2: Key N is added to the DNSKEY RRset and is then used to sign 538 the zone; existing signatures in the zone are not removed. This is 539 the activation time (Tact), after which the key is said to be active. 541 Event 3: After the current key (key N) has been in use for its 542 intended lifetime (Lzsk), the successor key (key N+1) is introduced 543 into the zone and starts being used to sign RRsets: neither the 544 current key nor the signatures created with it are removed. The 545 successor is key is now active and the current key is said to be 546 retired. This time is the retire time of the key (Tret); it is also 547 the activation time of the successor key (TactS). 549 Tret = Tact + Lzsk 551 Event 4: Before key N can be withdrawn from the zone, all RRsets that 552 need to be signed must have been signed by the successor key (key 553 N+1) and any old RRsets that do not include the new key or new RRSIGs 554 must have expired from caches. Note that the signatures are not 555 replaced - each RRset is signed by both the old and new key. 557 This takes Iret, the retire interval, given by the expression: 559 Iret = Dsgn + Dprp + max(TTLkey, TTLsig) 561 As before, Dsgn is the delay needed to ensure that all existing 562 RRsets have been signed with the new key and Dprp is the propagation 563 delay. The final term (the maximum of TTLkey and TTLsig) is the 564 period to wait for key and signature data associated with key N to 565 expire from caches. (TTLkey is the TTL of the DNSKEY RRset and 566 TTLsig is the maximum TTL of all the RRSIG records in the zone 567 created with the ZSK. The two may be different: although the TTL of 568 an RRSIG is equal to the TTL of the RRs in the associated RRset 569 [RFC4034], the DNSKEY RRset only needs to be signed with the KSK.) 571 At the end of this interval, key N is said to be dead. This occurs 572 at the dead time (Tdea) so: 574 Tdea = Tret + Iret 576 Event 5: At some later time key N and the signatures generated with 577 it can be removed from the zone. This is the removal time Trem, 578 given by: 580 Trem >= Tdea 582 3.2.3. Double-RRSIG Method 584 The timeline for a double-signature rollover is shown below. The 585 diagram follows the convention described in Section 3.2.1 587 |1||2| |3| |4||5| |6| |7||8| |9| |10| 588 | | | | | | | | | | 589 Key N | |<-Dsgn->| | |<--------Lzsk-------->|<-Iret->| | 590 | |<---IpubG-->| | | | | | | 591 | | | | | | | | | | 592 Key N+1 | | | | | |<-IpubG->| | | | 593 | | | | | | | | | | 594 Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem 596 ---- Time ----> 598 Figure 3: Timeline for a Double-Signature ZSK rollover. 600 Event 1: Key N is generated at the generate time (Tgen). Although 601 there is no reason why the key cannot be generated immediately prior 602 to its publication in the zone (Event 2), some implementations may 603 find it convenient to create a pool of keys in one operation and draw 604 from that pool as required. For this reason, it is shown as a 605 separate event. Keys that are available for use but not published 606 are said to be generated. 608 Event 2: Key N is used to sign the zone but existing signatures are 609 retained. Although the new ZSK is not published in the zone at this 610 point, for analogy with the other ZSK rollover methods and because 611 this is the first time that key information is visible (albeit 612 indirectly through the created signatures) this time is called the 613 publication time (Tpub). 615 Event 3: After the signing interval, Dsgn, all RRsets that need to be 616 signed have been signed by the new key. (As a result, all these 617 RRsets are now signed twice, once by the (still-absent) key N and 618 once by its predecessor. 620 Event 4: There is now a delay while the old signature information 621 expires from caches. This interval is given by the expression: 623 Dprp + TTLsig 625 As before, Dprp is the propagation delay and TTLsig is the maximum 626 TTL of all the RRSIG records in the zone created with the ZSK. 628 Again in analogy with other key rollover methods, this is defined as 629 key N's ready time (Trdy) and the key is said to be in the ready 630 state. (Although the key is not in the zone, it is ready to be 631 used.) The interval between the publication and ready times is the 632 publication interval of the signature, IpubG, i.e., 634 Trdy = Tpub + IpubG 636 where 638 IpubG = Dsgn + Dprp + TTLsig 640 Event 5: At some later time the predecessor key is removed and the 641 key N added to the DNSKEY RRset. As all the signed RRs have 642 signatures created by the old and new keys, the records can still be 643 authenticated. This time is the activation time (Tact) and the key 644 is now said to be active. 646 Event 6: At some point thought must be given to rolling the key. The 647 first step is to publish signatures created by the successor key (key 648 N+1) early enough for key N to be replaced after it has been active 649 for its scheduled lifetime. This occurs at TpubS (the publication 650 time of the successor), given by: 652 TpubS <= Tact + Lzsk - IpubG 654 Event 7: The signatures have propagated and the new key could be 655 added to the zone. This time is the ready time of the successor key 656 (TrdyS). 658 TrdyS = TpubS + IpubG 660 ... where IpubG is as defined above. 662 Event 8: At some later time key N is removed from the zone's DNSKEY 663 RRset and the successor key (key N+1) is added to it. This is the 664 retire time of the key (Tret). 666 Event 9: The signatures must remain in the zone for long enough that 667 the new DNSKEY RRset has had enough time to propagate to all caches. 668 Once caches contain the new DNSKEY, the old signatures are no longer 669 of use and can be considered to be dead as they cannot be validated 670 by any key. In analogy with other rollover methods, the time at 671 which this occurs is the dead time (Tdea), given by: 673 Tdea = Tret + Iret 675 ... where Iret is the retire interval, given by: 677 Iret = Dprp + TTLkey 679 Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset. 681 Event 10: At some later time the signatures can be removed from the 682 zone. In analogy with other rollover methods, this time is called 683 the remove time (Trem) and is given by: 685 Trem >= Tdea 687 3.3. Key-Signing Key Rollover Timelines 689 The following sections describe the rolling of a KSK. They show the 690 events in the lifetime of a key (referred to as "key N") and cover it 691 replacement by its successor (key N+1). 693 3.3.1. Double-Signature Method 695 The timeline for a double-signature rollover is shown below. The 696 diagram follows the convention described in Section 3.2.1 698 |1| |2| |3| |4| |5| 699 | | | | | 700 Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - - 701 | | | | | 702 Key N+1 | | | | | 703 | | | | | 704 Tgen Tpub Trdy Tsub Tact 706 ---- Time ----> 708 (continued ...) 710 |6| |7| |8| |9| |10| |11| 711 | | | | | | 712 Key N - - -------------Lksk------->|<-Iret->| | 713 | | | | | | 714 Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - 715 | | | | | | 716 TpubS TrdyS TsubS Tret Tdea Trem 718 ---- Time (cont) ----> 720 Figure 4: Timeline for a Double-Signature KSK rollover. 722 Event 1: Key N is generated at the generate time (Tgen). Although 723 there is no reason why the key cannot be generated immediately prior 724 to its publication in the zone (Event 2), some implementations may 725 find it convenient to create a pool of keys in one operation and draw 726 from that pool as required. For this reason, it is shown as a 727 separate event. Keys that are available for use but not published 728 are said to be generated. 730 Event 2: Key N is introduced into the zone; it is added to the DNSKEY 731 RRset, which is then signed by key N and all currently active KSKs. 732 (So at this point, the DNSKEY RRset is signed by both key N and its 733 predecessor KSK. If other KSKs were active, it is signed by these as 734 well.) This is the publication time (Tpub); after this the key is 735 said to be published. 737 Event 3: Before it can be used, the key must be published for long 738 enough to guarantee that any validating resolver that has a copy of 739 the DNSKEY RRset in its cache will have a copy of the RRset that 740 includes this key: in other words, that any prior cached information 741 about the DNSKEY RRset has expired. 743 The interval is the publication interval (Ipub) and, for the second 744 or subsequent KSKs in the zone, is given by: 746 Ipub = DprpC + TTLkey 748 ... where DprpC is the propagation delay for the child zone (the zone 749 containing the KSK being rolled) and TTLkey the TTL for the DNSKEY 750 RRset. The time at which this occurs is the key's ready time, Trdy, 751 given by: 753 Trdy = Tpub + Ipub 755 (The case of introducing the first KSK into the zone is discussed in 756 Section 3.3.5.) 758 Event 4: At some later time, the DS record corresponding to the new 759 KSK is submitted to the parent zone for publication. This time is 760 the submission time, Tsub. 762 Event 5: The DS record is published in the parent zone. As this is 763 the point at which all information for authentication - both DNSKEY 764 and DS record - is available in the two zones, in analogy with other 765 rollover methods, this is called the activation time of the key 766 (Tact): 768 Tact = Tsub + Dreg 770 ... where Dreg is the registration delay, the time taken after the DS 771 record has been received by the parent zone manager for it to be 772 placed in the zone. (Parent zones are often managed by different 773 entities, and this term accounts for the organisational overhead of 774 transferring a record.) 776 Event 6: While key N is active, thought needs to be given to its 777 successor (key N+1). At some time before the scheduled end of the 778 KSK lifetime, the successor KSK is published in the zone. (As 779 before, this means that the DNSKEY RRset is signed by both the 780 current and successor KSK.) This time is the publication time of the 781 successor key, TpubS, given by: 783 TpubS <= Tact + Lksk - Dreg - Ipub 785 ... where Lksk is the scheduled lifetime of the KSK. 787 Event 7: After an interval Ipub, key N+1 becomes ready (in that all 788 caches that have a copy of the DNSKEY RRset have a copy of this key). 789 This time is the ready time of the successor (TrdyS). 791 Event 8: At the submission time of the successor (TsubS), the DS 792 record corresponding to key N+1 is submitted to the parent zone. 794 Event 9: The successor DS record is published in the parent zone and 795 the current DS record withdrawn. The current key is said to be 796 retired and the time at which this occurs is Tret, given by: 798 Tret = Tact + Lksk 800 Event 10: Key N must remain in the zone until any caches that contain 801 a copy of the DS RRset have a copy containing the new DS record. 802 This interval is the retire interval, given by: 804 Iret = DprpP + TTLds 806 ... where DprpP is the propagation delay in the parent zone and TTLds 807 the TTL of a DS record in the parent zone. 809 As the key is no longer used for anything, is said to be dead. This 810 point is the dead time (Tdea), given by: 812 Tdea = Tret + Iret 814 Event 11: At some later time, key N is removed from the zone's DNSKEY 815 RRset (at the remove time Trem); the key is now said to be removed. 817 Trem >= Tdea 819 3.3.2. Double-DS Method 821 The timeline for a double-DS rollover is shown below. The diagram 822 follows the convention described in Section 3.2.1 823 |1| |2| |3| |4| |5| |6| 824 | | | | | | 825 Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - 826 | | | | | | 827 Key N+1 | | | | |<---->|<--Dreg+IpubP- - - 828 | | | | | | 829 Tgen Tsub Tpub Trdy Tact TsubS 831 ---- Time ----> 833 (continued ...) 835 |7| |8| |9| |10| 836 | | | | 837 Key N - - -----Lksk---------->|<-Iret->| | 838 | | | | 839 Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - 840 | | | | 841 TrdyS Tret Tdea Trem 843 ---- Time ----> 845 Figure 5: Timeline for a Double-DS KSK rollover. 847 Event 1: Key N is generated at the generate time (Tgen). Although 848 there is no reason why the key cannot be generated immediately prior 849 to its publication in the zone (Event 2), some implementations may 850 find it convenient to create a pool of keys in one operation and draw 851 from that pool as required. For this reason, it is shown as a 852 separate event. Keys that are available for use but not published 853 are said to be generated. 855 Event 2: The DS RR is submitted to the parent zone for publication. 856 This time is the submission time, Tsub. 858 Event 3: After the registration delay, Dreg, the DS record is 859 published in the parent zone. This is the publication time Tpub, 860 given by: 862 Tpub = Tsub + Dreg 864 Event 4: At some later time, any cache that has a copy of the DS 865 RRset will have a copy of the DS record for key N. At this point, key 866 N, if introduced into the DNSKEY RRset, could be used to validate the 867 zone. For this reason, this time is known as the key's ready time, 868 Trdy, and is given by: 870 Trdy = Tpub + IpubP 872 IpubP is the parent publication interval and is given by the 873 expression: 875 IpubP = DprpP + TTLds 877 ... where DprpP is the propagation delay for the parent zone and 878 TTLds the TTL assigned to DS records in that zone. 880 Event 5: At some later time, the key rollover takes place and the new 881 key (key N) is introduced into the DNSKEY RRset and used to sign 882 that. 884 As both the old and new DS records have been in the parent zone long 885 enough to ensure that they are in caches that contain the DS RRset, 886 the zone can be authenticated throughout the rollover - the 887 validating resolver either has a copy of the DNSKEY RRset 888 authenticated by the predecessor key, or it has a copy of the updated 889 RRset authenticated with the new key. 891 This time is key N's activation time (Tact) and at this point the key 892 is said to be active. 894 Event 6: At some point thought must be given to key replacement. The 895 DS record for the successor key must be submitted to the parent zone 896 at a time such that when the current key is withdrawn, any cache that 897 contains the zone's DS records has data about the DS record of the 898 successor key. The time at which this occurs is the submission time 899 of the successor, given by: 901 TsubS <= Tact + Lksk - IpubP - Dreg 903 ... where Lksk is the lifetime of key N according to policy. 905 Event 7: The successor key (key N+1) enters the ready state, i.e., 906 its DS record is now in caches that contain the parent DS RRset. 907 This is the ready time of the successor key, TrdyS. 909 (The interval between events 6 and 7 for the key N+1 correspond to 910 the interval between events 2 and 4 for key N) 912 Event 8: When key N has been active for its lifetime (Lksk), it is 913 replaced in the DNSKEY RRset by key N+1; the RRset is then signed 914 with the new key. This is the retire time (Tret) of key N, given by: 916 Tret = Tact + Lksk 918 Event 9: At some later time, all copies of the old DNSKEY RRset have 919 expired from caches and the old DS record is no longer needed. In 920 analogy with other rollover methods, this is called the dead time, 921 Tdea, and is given by: 923 Tdea = Tret + Iret 925 ... where Iret is the retire interval, given by: 927 Iret = DprpC + TTLkey 929 As before, this term includes DprpC, the time taken to propagate the 930 RRset change through the master-slave hierarchy of the child zone and 931 TTLkey, the time taken for the DNSKEY RRset to expire from caches. 933 Event 10: At some later time, the DS record is removed from the 934 parent zone. In analogy with other rollover methods, this is the 935 removal time (Trem), given by: 937 Trem >= Tdea 939 3.3.3. Double-RRset Method 941 The timeline for a double-RRset rollover is shown below. The diagram 942 follows the convention described in Section 3.2.1 944 |1| |2| |3| |4| |5| |6| 945 | | | | | | 946 Key N | |<-Ipub->|<-----Lksk----->| | 947 | | | | | | 948 Key N+1 | | | |<-Ipub->| | 949 | | | | | | 950 Tgen Tpub Tact TpubS Tret Trem 952 ---- Time ----> 954 Figure 6: Timeline for a Double-RRset KSK rollover. 956 Event 1: Key N is generated at the generate time (Tgen). Although 957 there is no reason why the key cannot be generated immediately prior 958 to its publication in the zone (Event 2), some implementations may 959 find it convenient to create a pool of keys in one operation and draw 960 from that pool as required. For this reason, it is shown as a 961 separate event. Keys that are available for use but not published 962 are said to be generated. 964 Event 2: The key is added to and used for signing the DNSKEY RRset 965 and is thereby published in the zone. At the same time the 966 corresponding DS record is submitted to the parent zone for 967 publication. This time is the publish time (Tpub) and the key is now 968 said to be published. 970 Event 3: At some later time, the DS record is published in the parent 971 zone and at some time after that, the updated information has reached 972 all caches: any cache that holds a DNSKEY RRset from the child zone 973 will have a copy that includes the new KSK, and any cache that has a 974 copy of the parent DS RRset will have a copy that includes the new DS 975 record. 977 The time at which this occurs is called the activation time of the 978 new KSK (Tact), given by: 980 Tact = Tpub + Ipub 982 ... where Ipub is the publication interval, given by: 984 Ipub = max(IpubP, IpubC), 986 IpubP being the publication interval in the parent zone and IpubC the 987 publication interval in the child zone. The parent zone's 988 publication interval is given by: 990 IpubP = Dreg + DprpP + TTLds 992 where Dreg is the registration delay, the time taken for the DS 993 record to be published in the parent zone. DprpP is the parent 994 zone's propagation delay and TTLds is the TTL of the DS record in 995 that zone. 997 The child's publication interval is given by a similar equation: 999 IpubC = DprpC + TTLkey 1001 ... where DprpC is the propagation delay in the child zone and TTLkey 1002 the TTL of a DNSKEY record. 1004 Event 4: At some point we need to give thought to key replacement. 1005 The successor key (key N+1) must be introduced into the zone (and its 1006 DS record submitted to the parent) at a time such that it becomes 1007 active when the current key has been active for its lifetime, Lksk. 1008 This time is TpubS, the publication time of the successor key, and is 1009 given by: 1011 TpubS <= Tact + Lksk - Ipub 1013 ... where Lksk is the lifetime of the KSK. 1015 Event 5: Key N+1's DNSKEY and DS records are in any caches that 1016 contain the child zone DNSKEY and/or the parent zone DS RR, and so 1017 the zone can be validated with the new key. This is the activation 1018 time of the successor key (TactS) and by analogy with other rollover 1019 methods, it is also the retire time of the current key. Since at 1020 this time the zone can be validated by the successor key, there is no 1021 reason to keep the current key in the zone and the time can also be 1022 regarded as the current key's dead time. Thus: 1024 Tret = Tdea = TactS = Tact + Lksk 1026 Event 6: At some later time, the key N's DS and DNSKEY records are 1027 removed from their respective zones. In analogy with other rollover 1028 methods, this is the removal time (Trem), given by: 1030 Trem >= Tdea 1032 3.3.4. Interaction with Configured Trust Anchors 1034 Although the preceding sections have been concerned with rolling KSKs 1035 where the trust anchor is a DS record in the parent zone, zone 1036 managers may want to take account of the possibility that some 1037 validating resolvers may have configured trust anchors directly. 1039 Rolling a configured trust anchor is dealt with in [RFC5011]. It 1040 requires introducing the KSK to be used as the trust anchor into the 1041 zone for a period of time before use, and retaining it (with the 1042 "revoke" bit set) for some time after use. 1044 3.3.4.1. Addition of KSK 1046 When the new key is introduced, the publication interval (Ipub) in 1047 the Double-Signature and Double-RRset methods should also be subject 1048 to the condition: 1050 Ipub >= Dprp + max(Itrp, TTLkey) 1052 ... where the right hand side of the expression is the time taken for 1053 the change to propagate to all nameservers for the zone plus the 1054 "trust point" interval. This latter term is the interval required to 1055 guarantee that a resolver configured for the automatic update of keys 1056 from a particular trust point will see at least two validated DNSKEY 1057 RRsets containing the new key (a requirement from [RFC5011], section 1058 2.4.1). It is defined by the expression: 1060 Itrp >= (2 * queryInterval) + (n * retryTime) 1062 ... where queryInterval and retryTime are as defined in section 2.3 1063 of [RFC5011]. "n" is the total number of retries needed by the 1064 resolver during the two attempts to get the DNSKEY RRset. 1066 The first term of the expression (2 * queryInterval) represents the 1067 time to obtain two validated DNSKEY RRsets. The second term (n * 1068 retryTime) is a safety margin, with the value of "n" reflecting the 1069 degree of confidence in the communication between a resolver and the 1070 trust point. 1072 In the Double-DS method, instead of swapping the KSK RRs in a single 1073 step, there must now be a period of overlap. In other words, the new 1074 KSK must be introduced into the zone at least: 1076 DprpC + max(Itrp, TTLkey) 1078 ... before the switch is made. 1080 3.3.4.2. Removal of KSK 1082 The timeline for the removal of the key in all methods is modified by 1083 introducing a new state, "revoked". When the key reaches its dead 1084 time, instead of being declared "dead", it is revoked; the "revoke" 1085 bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed 1086 with the current and revoked keys. The key is maintained in this 1087 state for the "revoke" interval, Irev, given by: 1089 Irev >= 30 days 1091 ... 30 days being the [RFC5011] remove hold-down time. After this 1092 time, the key is dead and can be removed from the zone. 1094 3.3.5. Introduction of First Keys 1096 There are no timing considerations associated with the introduction 1097 of the first keys into a zone other that they must be introduced and 1098 the zone validly signed before a chain of trust to the zone is 1099 created. 1101 This is important: in the case of a secure parent, it means ensuring 1102 that the DS record is not published in the parent zone until there is 1103 no possibility that a validating resolver can obtain the record yet 1104 is not able to obtain the corresponding DNSKEY. In the case of an 1105 insecure parent, i.e., the initial creation of a new security apex, 1106 it is not possible to guarantee this. It is up to the operator of 1107 the validating resolver to wait for the new KSK to appear at all 1108 servers for the zone before configuring the trust anchor. 1110 4. Standby Keys 1112 Although keys will usually be rolled according to some regular 1113 schedule, there may be occasions when an emergency rollover is 1114 required, e.g., if the active key is suspected of being compromised. 1115 The aim of the emergency rollover is to allow the zone to be re- 1116 signed with a new key as soon as possible. As a key must be in the 1117 ready state to sign the zone, having at least one additional key (a 1118 standby key) in this state at all times will minimise delay. 1120 In the case of a ZSK, a standby key only really makes sense with the 1121 Pre-Publication method. A permanent standby DNSKEY RR should be 1122 included in the zone or successor keys could be introduced as soon as 1123 possible after a key becomes active. Either way results in one or 1124 more additional ZSKs in the DNSKEY RRset that can immediately be used 1125 to sign the zone if the current key is compromised. 1127 (Although in theory the mechanism could be used with both the Double- 1128 Signature and Double-RRSIG methods, it would require pre-publication 1129 of the signatures. Essentially, the standby key would be permanently 1130 active, as it would have to be periodically used to renew signatures. 1131 Zones would also permanently require two sets of signatures.) 1133 It is also possible to have a standby KSK. The Double-Signature 1134 method requires that the standby KSK be included in the DNSKEY RRset; 1135 rolling the key then requires just the introduction of the DS record 1136 in the parent. Note that the standby KSK should also be used to sign 1137 the DNSKEY RRset. As the RRset and its signatures travel together, 1138 merely adding the KSK without using it to sign the DNSKEY RRset does 1139 not provide the desired time saving: for a KSK to be used in a 1140 rollover the DNSKEY RRset must be signed with it, and this would 1141 introduce a delay while the old RRset (not signed with the new key) 1142 expires from caches. 1144 The idea of a standby KSK in the Double-RRset rollover method 1145 effectively means having two active keys (as the standby KSK and 1146 associated DS record would both be published at the same time in 1147 their respective zones). 1149 Finally, in the Double-DS method of rolling a KSK, it is not a 1150 standby key that is present, it is a standby DS record in the parent 1151 zone. 1153 Whatever algorithm is used, the standby item of data can be included 1154 in the zone on a permanent basis, or be a successor introduced as 1155 early as possible. 1157 5. Algorithm Considerations 1159 The preceding sections have implicitly assumed that all keys and 1160 signatures are created using a single algorithm. However, [RFC4035] 1161 (section 2.4) states that "There MUST be an RRSIG for each RRset 1162 using at least one DNSKEY of each algorithm in the zone apex DNSKEY 1163 RRset". 1165 Except in the case of an algorithm rollover - where the algorithms 1166 used to create the signatures are being changed - there is no 1167 relationship between the keys of different algorithms. This means 1168 that they can be rolled independently of one another. In other 1169 words, the key rollover logic described above should be run 1170 separately for each algorithm; the union of the results is included 1171 in the zone, which is signed using the active key for each algorithm. 1173 6. Limitation of Scope 1175 This document represents current thinking at the time of publication. 1176 However, the subject matter is evolving and it is more than likely 1177 that this document will need to be revised in the future. 1179 Some of the techniques and ideas that DNSSEC operators are 1180 considering differ from this those described in this document. Of 1181 particular interest are alternatives to the strict split into KSK and 1182 ZSK key roles and the consequences for rollover logic from partial 1183 signing (i.e., when the new key initially only signs a fraction of 1184 the zone while leaving other signatures generated by the old key in 1185 place). 1187 Furthermore, as noted in section 5, this document covers only rolling 1188 keys of the same algorithm: it does not cover transitions between 1189 algorithms. The timing issues associated with algorithm rollovers 1190 will require a separate document. 1192 The reader is therefore reminded that DNSSEC is, as of date of 1193 publication, in the early stages of deployment, and best practices 1194 may further develop over time. 1196 7. Summary 1198 For ZSKs, "Pre-Publication" is generally considered to be the 1199 preferred way of rolling keys. As shown in this document, the time 1200 taken to roll is wholly dependent on parameters under the control of 1201 the zone manager. 1203 In contrast, "Double-RRset" is the most efficient method for KSK 1204 rollover due to the ability to have new DS records and DNSKEY RRsets 1205 propagate in parallel. The time taken to roll KSKs may depend on 1206 factors related to the parent zone if the parent is signed. For 1207 zones that intend to comply with the recommendations of [RFC5011], in 1208 virtually all cases the rollover time will be determined by the 1209 RFC5011 "add hold-down" and "remove hold-down" times. It should be 1210 emphasized that this delay is a policy choice and not a function of 1211 timing values and that it also requires changes to the rollover 1212 process due to the need to manage revocation of trust anchors. 1214 Finally, the treatment of emergency key rollover is significantly 1215 simplified by the introduction of standby keys as standard practice 1216 during all types of rollovers. 1218 8. IANA Considerations 1220 This memo includes no request to IANA. 1222 9. Security Considerations 1224 This document does not introduce any new security issues beyond those 1225 already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. 1227 10. Acknowledgements 1229 The authors gratefully acknowledge help and contributions from Roy 1230 Arends, Matthijs Mekking and Wouter Wijngaards. 1232 11. Normative References 1234 [I-D.ietf-dnsop-rfc4641bis] 1235 Kolkman, O. and M. Mekking, "DNSSEC Operational Practices, 1236 Version 2", draft-ietf-dnsop-rfc4641bis-11 (work in 1237 progress), April 2012. 1239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1240 Requirement Levels", BCP 14, RFC 2119, March 1997. 1242 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1243 Rose, "DNS Security Introduction and Requirements", 1244 RFC 4033, March 2005. 1246 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1247 Rose, "Resource Records for the DNS Security Extensions", 1248 RFC 4034, March 2005. 1250 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1251 Rose, "Protocol Modifications for the DNS Security 1252 Extensions", RFC 4035, March 2005. 1254 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1255 Trust Anchors", RFC 5011, September 2007. 1257 Appendix A. List of Symbols 1259 The document defines a number of symbols, all of which are listed 1260 here. All are of the form: 1262 All symbols used in the text are of the form: 1264 1266 where: 1268 is an upper-case character indicating what type the symbol is. 1269 Defined types are: 1271 D delay: interval that is a feature of the process 1273 I interval between two events 1275 L lifetime: interval set by the zone manager 1277 T a point in time 1279 TTL TTL of a record 1281 I and T and TTL are self-explanatory. Like I, both D and L are time 1282 periods, but whereas I values are intervals between two events (even 1283 if the events are defined in terms of the interval, e.g., the dead 1284 time occurs "retire interval" after the retire time), D and L are 1285 fixed intervals: a "D" interval (delay) is a feature of the process, 1286 probably outside control of the zone manager, whereas an "L" interval 1287 (lifetime) is chosen by the zone manager and is a feature of policy. 1289 is lower-case and defines what object or event the variable is 1290 related to, e.g., 1291 act activation 1293 pub publication 1295 ret retire 1297 Finally, is a capital letter that distinguishes between the 1298 same variable applying to different instances of an object and is one 1299 of: 1301 C child 1303 G signature 1305 P parent 1307 S successor 1309 The list of variables used in the text is: 1311 Dprp Propagation delay. The amount of time for a change made at 1312 a master nameserver to propagate to all the slave 1313 nameservers. 1315 DprpC Propagation delay in the child zone. 1317 DprpP Propagation delay in the parent zone. 1319 Dreg Registration delay: the time taken for a DS record 1320 submitted to a parent zone to appear in it. As a parent 1321 zone is often managed by a different organisation to that 1322 managing the child zone, the delays associated with passing 1323 data between zones is captured by this term. 1325 Dsgn Signing delay. After the introduction of a new ZSK, the 1326 amount of time taken for all the RRs in the zone to be 1327 signed with it. 1329 Ipub Publication interval. The amount of time that must elapse 1330 after the publication of a key before it can be assumed 1331 that any resolvers that have the DNSKEY RRset cached have a 1332 copy of this key. 1334 IpubC Publication interval in the child zone. 1336 IpubG Publication interval for the signature created by a ZSK: 1337 the amount of time that must elapse after the signature has 1338 been created before it can be assumed that any resolves 1339 that have the RRset and RRSIG cached have a copy of this 1340 signature. 1342 IpubP Publication interval in the parent zone. 1344 Iret Retire interval. The amount of time that must elapse after 1345 a key enters the retire state for any signatures created 1346 with it to be purged from validating resolver caches. 1348 Irev Revoke interval. The amount of time that a KSK must remain 1349 published with the revoke bit set to satisfy [RFC5011] 1350 considerations. 1352 Itrp Trust-point interval. The amount of time that a trust 1353 anchor must be published for to guarantee that a resolver 1354 configured for an automatic update of keys will see the new 1355 key at least twice. 1357 Lksk Lifetime of a key-signing key. This is the intended amount 1358 of time for which this particular KSK is regarded as the 1359 active KSK. Depending on when the key is rolled-over, the 1360 actual lifetime may be longer or shorter than this. 1362 Lzsk Lifetime of a zone-signing key. This is the intended 1363 amount of time for which the ZSK is used to sign the zone. 1364 Depending on when the key is rolled-over, the actual 1365 lifetime may be longer or shorter than this. 1367 Tact Activation time of the key; the time at which the key is 1368 regarded as the principal key for the zone. 1370 TactS Activation time of the successor key. 1372 Tdea Dead time of a key. Applicable only to ZSKs, this is the 1373 time at which any record signatures held in validating 1374 resolver caches are guaranteed to be created with the 1375 successor key. 1377 Tgen Generate time of a key. The time that a key is created. 1379 Tpub Publication time of a key. The time that a key appears in 1380 a zone for the first time. 1382 TpubS Publication time of the successor key. 1384 Trem Removal time of a key. The time at which a key is removed 1385 from the zone. 1387 Tret Retire time of a key. The time at which a successor key 1388 starts being used to sign the zone. 1390 Trdy Ready time of a key. The time at which it can be 1391 guaranteed that validating resolvers that have key 1392 information from this zone cached have a copy of this key 1393 in their cache. (In the case of KSKs, should the 1394 validating resolvers also have DS information from the 1395 parent zone cached, the cache must include information 1396 about the DS record corresponding to the key.) 1398 TrdyS Ready time of a successor key. 1400 Tsub Submission time - the time at which the DS record of a KSK 1401 is submitted to the parent. 1403 TsubS Submission time of the successor key. 1405 TTLds Time to live of a DS record (in the parent zone). 1407 TTLkey Time to live of a DNSKEY record. (By implication, this is 1408 also the time to live of the signatures on the DNSKEY 1409 RRset.) 1411 TTLsig The maximum time to live of all the RRSIG records in the 1412 zone that were created with the ZSK. 1414 Appendix B. Change History (To be removed on publication) 1416 o draft-ietf-dnsop-dnssec-key-timing-03 1417 * Clarifications of and corrections to wording (Marc Lampo, Alfred 1418 Hoenes). 1419 * Updated timings related to trust anchor interaction (Matthijs 1420 Mekking). 1421 * Updated RFC 4641 reference to 4641bis (Alfred Hoenes). 1422 * Moved change history to end of document (Alfred Hoenes). 1424 o draft-ietf-dnsop-dnssec-key-timing-02 1425 * Significant re-wording of some sections. 1426 * Removal of events noting change of state of predecessor key from 1427 ZSK Double-RRSIG and Double-Signature methods. 1428 * Change order of bullet points (and some wording) in section 1.1. 1430 * Remove discussion of advantages and disadvantages of key roll 1431 methods from section 2: draft is informative and does not give 1432 recommendations. 1433 * Removal of discussion of upper limit to retire time relationship 1434 to signature lifetime. 1435 * Remove timing details of first key in the zone and move 1436 discussion of first signing of a zone to later in the document). 1437 (Matthijs Mekking) 1438 * Removal of redundant symbols from Appendix A. 1440 o draft-ietf-dnsop-dnssec-key-timing-01 1441 * Added section on limitation of scope. 1443 o draft-ietf-dnsop-dnssec-key-timing-00 1444 * Change to author contact details. 1446 o draft-morris-dnsop-dnssec-key-timing-02 1447 * General restructuring. 1448 * Added descriptions of more rollovers (IETF-76 meeting). 1449 * Improved description of key states and removed diagram. 1450 * Provided simpler description of standby keys. 1451 * Added section concerning first key in a zone. 1452 * Moved [RFC5011] to a separate section. 1453 * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion 1454 Lloyd, Tony Finch). 1456 o draft-morris-dnsop-dnssec-key-timing-01 1457 * Use latest boilerplate for IPR text. 1458 * List different ways to roll a KSK (acknowledgements to Mark 1459 Andrews). 1460 * Restructure to concentrate on key timing, not management 1461 procedures. 1462 * Change symbol notation (Diane Davidowicz and others). 1463 * Added key state transition diagram (Diane Davidowicz). 1464 * Corrected spelling, formatting, grammatical and style errors 1465 (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya). 1466 * Added note that in the case of multiple algorithms, the 1467 signatures and rollovers for each algorithm can be considered as 1468 more or less independent (Alfred Hoenes). 1469 * Take account of the fact that signing a zone is not atomic 1470 (Chris Thompson). 1471 * Add section contrasting pre-publication rollover with double 1472 signature rollover (Matthijs Mekking). 1473 * Retained distinction between first and subsequent keys in 1474 definition of initial publication interval (Matthijs Mekking). 1476 o draft-morris-dnsop-dnssec-key-timing-00 1477 Initial draft. 1479 Authors' Addresses 1481 Stephen Morris 1482 Internet Systems Consortium 1483 950 Charter Street 1484 Redwood City, CA 94063 1485 USA 1487 Phone: +1 650 423 1300 1488 Email: stephen@isc.org 1490 Johan Ihren 1491 Netnod 1492 Franzengatan 5 1493 Stockholm, SE-112 51 1494 Sweden 1496 Phone: +46 8615 8573 1497 Email: johani@autonomica.se 1499 John Dickinson 1500 Sinodun Internet Technologies Ltd 1501 Stables 4 Suite 11, Howbery Park 1502 Wallingford, Oxfordshire OX10 8BA 1503 UK 1505 Phone: +44 1491 818120 1506 Email: jad@sinodun.com