idnits 2.17.1 draft-morris-dnsop-dnssec-key-timing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 17, 2009) is 5541 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4641 (Obsoleted by RFC 6781) Summary: 1 error (**), 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 Nominet 4 Intended status: Informational J. Ihren 5 Expires: August 21, 2009 Autonomica 6 J. Dickinson 7 February 17, 2009 9 DNSSEC Key Timing Considerations 10 draft-morris-dnsop-dnssec-key-timing-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 21, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 RFC 4641 gives a detailed overview of the operational considerations 50 involved in running a DNSSEC-secured zone, including key rollovers. 51 This document expands on the previous work, and discusses timing 52 considerations in greater depth. It explicitly identifies the 53 relationships between the various time parameters, and gives a 54 suggested algorithm for key rollover in a DNSSEC-secured zone. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Zone-Signing Keys . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Emergency Zone-Signing Keys . . . . . . . . . . . . . . . 7 64 2.2.1. Emergency Key Replacement . . . . . . . . . . . . . . 7 65 2.2.2. Emergency Key Use . . . . . . . . . . . . . . . . . . 8 66 2.3. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 9 67 2.3.1. Actual and Estimated Times . . . . . . . . . . . . . . 9 68 2.3.2. Practical Timing Considerations . . . . . . . . . . . 9 69 2.3.3. ZSK Management Procedure . . . . . . . . . . . . . . . 10 70 3. Key-Signing Keys . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.2. Emergency Key-Signing Keys . . . . . . . . . . . . . . . . 15 73 3.3. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . 15 74 3.4. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 15 75 3.4.1. Actual and Estimated Times . . . . . . . . . . . . . . 15 76 3.4.2. Practical Timing Considerations . . . . . . . . . . . 16 77 3.4.3. KSK Management Procedure . . . . . . . . . . . . . . . 16 78 4. Running the Key Management Procedures . . . . . . . . . . . . 17 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 82 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 83 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 When a zone is secured with DNSSEC, [RFC4641] recommends that the 89 keys used to sign the zone are periodically replaced (or "rolled 90 over"). In order to implement this recommendation, the keys need to 91 be managed in order to allow them to be introduced into and removed 92 from the zone at the appropriate times. Considerations that must be 93 taken into account are: 95 o Key and signature records are not only held at the authoritative 96 nameserver; they are also cached at client resolvers. The data on 97 these can be interlinked, e.g. a validator may try to validate a 98 signature retrieved from a cache with a key obtained separately. 100 o To allow for emergency re-signing, additional keys (over and above 101 those used to sign the zone) need to be present. 103 o A query for the key RRset returns all DNSKEY records in the zone. 104 As there is limited space in the UDP packet (even with EDNS0 105 support), stale key records must be periodically removed. (For 106 the same reason, the number of emergency keys in the zone should 107 be restricted to the minimum required to support the key 108 management policy.) 110 o Zone "boot-strapping" events, where a zone is signed for the first 111 time, can be common in configurations where a large number of 112 zones are being served. Procedures should be able to cope with 113 the introduction of keys into the zone for the first time as well 114 as "steady-state", where the records are being replaced as part of 115 normal zone maintenance. 117 Management policy, e.g. how long a key is used for, also needs to be 118 taken into account. However, the point of key management logic is 119 not to ensure that a "rollover" is completed at a certain time but 120 rather to ensure that no changes are made to the state of keys 121 published in the zone until it is "safe" to do so. In other words, 122 although key management logic enforces policy, it may not enforce it 123 strictly. 125 1.1. Terminology 127 The terminology used in this document is as defined in [RFC4033] and 128 [RFC4641]. 130 1.2. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Zone-Signing Keys 138 2.1. Key Timeline 140 The following diagram shows the time line of a particular ZSK (zone- 141 signing key) and its replacement by its successor. Time increases 142 along the horizontal scale from left to right and the vertical lines 143 indicate events in the life of the key. The events are numbered: 144 significant times and time intervals are marked. 146 |1| |2| |3| |4| |5| |6| |7| |8| |9| 147 | | | | | | | | | 148 Key N | |<-Ip->|<--->|<-------Lz------->|<-It->|<--->| 149 | | | | | | | | | 150 Key N+1 | | | | |<-Ip->|<--->|<--------Lz-- - - 151 | | | | | | | | | 152 Tg Tp Tr Ta Tps Tt Td Tm 154 ---- Time ----> 156 Timeline for a ZSK rollover. 158 Figure 1 160 Event 1: key N is generated at the generate time (Tg). Although 161 there is no reason why the key cannot be generated immediately prior 162 to publication in the zone (Event 2), some implementations may find 163 it convenient to create a pool of keys in one operation and draw from 164 that pool as required. For this reason, it is shown as a separate 165 event. Keys that are generated but not published are said to be in 166 the generate state. 168 Event 2: key N's DNSKEY record is put into the zone, i.e. it is added 169 to the DNSKEY RRset which is then re-signed with the current key- 170 signing key. Note that key N is not yet used to sign records. The 171 time at which this occurs is the key's publication time (Tp), and the 172 key is now in the published state. 174 Event 3: before it can be used, the key must stay in the published 175 state for long enough to guarantee that any resolver that has a copy 176 of the DNSKEY RRset from the zone in its cache will have a copy of 177 the RRset that includes this key record: in other words, that any 178 prior cached information about the DNSKEY RRset has expired. 180 The interval is the publication interval (Ip) and, for the second or 181 subsequent keys in the zone, is given by: 183 Ip = TTLkey + Dp 185 Here, TTLkey is the time-to-live (TTL) for the DNSKEY records in the 186 zone. The other term is Dp (the propagation delay), which is 187 included because of the finite time taken for any change introduced 188 at the master to replicate to all slave servers. The delay depends 189 on the depth of the master-slave hierarchy. 191 In the case of the first key in the zone, Ip is slightly different 192 because it is not information about a DNSKEY RRset that may be cached 193 at downstream validators, it is information about its absence. In 194 this case: 196 Ip = C + Dp 198 where C is the negative cache time from the zone's SOA record, 199 calculated as described in [RFC2308] as the minimum of the TTL of the 200 SOA record itself (TTLsoa), and the "minimum" field in the record's 201 parameters (SOAmin), i.e. 203 C = min(TTLsoa, SOAmin) 205 The two expressions for Ip may be conveniently combined as: 207 Ip = max(TTLkey, C) + Dp 209 After a delay of Ip, the key is in the ready state and can be used to 210 sign records. The time at which this event occurs is the key's ready 211 time (Tr), which is given by: 213 Tr = Tp + Ip 215 Event 4: at some later time, the key is used to sign the zone. This 216 point is the activation time (Ta) and after this, the key is said to 217 be in the active state. 219 Event 5: while this key is active, thought must be given to its 220 successor. As with the introduction of the present key into the 221 zone, the successor key will need to be published at least Ip before 222 it is used. Denoting the publication time of the successor key by 223 Tps, then: 225 Tps <= Ta + Lz - Ip 227 Here, Lz is the length of time for which a ZSK will be used (the ZSK 228 lifetime). It should be noted that unlike the publication interval, 229 Lz is not determined by timing logic, but by key management policy. 230 Lz will be set by the operator according to their assessment of the 231 risks posed by continuing to use a key and the risks associated with 232 key rollover. However, operational considerations may mean a key 233 lives for slightly more or less than Lz. 235 Event 6: while the present ZSK is still active, its successor moves 236 into the ready state. From this time onwards, it could be used to 237 sign the zone. 239 Event 7: at some point the decision is made to start signing the zone 240 using the successor key. This will be when the current key has been 241 in use for an interval equal to the ZSK lifetime, hence: 243 Tt = Ta + Lz 245 This point in time is the retire time (Tt) of key N; after this the 246 key is said to be retired. (This time is also the point at which the 247 successor key becomes active.) 249 Event 8: the retired key needs to be retained in the zone whilst any 250 resolvers still have RRSIG records in their cache that were created 251 using the key. (It is possible that a resolver could have an 252 unexpired RRSIG record and an expired DNSKEY RRset in the cache when 253 it is asked to provide both to a client. In this case the DNSKEY 254 RRset would need to be looked up again.) This means that once the 255 key is no longer used to sign records, it should be retained in the 256 zone for at least the retire interval (It) given by: 258 It = TTLsig + Dp 260 TTLsig is the TTL of the RRSIG records and Dp the propagation delay, 261 the latter being included in the equation for the same reason as 262 given in the description of event 3. Once this time has passed, the 263 key can be considered dead. This time is the dead time (Td), given 264 by: 266 Td = Tt + It 268 Event 9: at any time after the key becomes dead, it can be removed 269 from the zone and the DNSKEY RRset re-signed with the current key- 270 signing key. This time is the removal time (Tm), given by: 272 Tm >= Td 274 2.2. Emergency Zone-Signing Keys 276 Although ZSKs will usually be generated according to some regular 277 schedule, there may be occasions when an emergency ZSK rollover is 278 required, e.g. if a key is suspected of being compromised. The aim 279 of the emergency key rollover is to allow the zone to be re-signed 280 with the new key as soon as possible. As a key must be in the ready 281 state to sign the zone, it may be advisable to have at least one 282 spare ZSK in that state at all times. 284 2.2.1. Emergency Key Replacement 286 One way to handle this is to regard successor keys as emergency keys, 287 and to introduce them in the zone as early as possible. A 288 modification of Figure 1 illustrates this: 290 |1| |2| |3| |4| 291 | | | | 292 Key N - - - -- Lz ------------->| | 293 | | | | 294 Key N+1 - --------------------->|<-----Lz------>| 295 | | | | 296 Key N+2 |<--Ip-->|<---------------------->|<--Lz-- - - 297 | | | | 299 ---- Time ----> 301 Timeline showing emergency key replacement. 303 Figure 2 305 In this figure, it is assumed that key N is initially in the active 306 state and that key N+1 is in the ready state. Key N+1 is the 307 successor to key N but is regarded as the emergency key until the 308 time comes to use it to sign the zone. 310 Event 1: At least Ip (publication interval) before key N's retire 311 time, key N+2 is published in the zone. 313 Event 2: key N+2 moves into the ready state. 315 Event 3: key N is retired and key N+1 becomes active (as described in 316 figure 1, events 7 - 9). Key N+2 is now regarded as the emergency 317 key. 319 Event 4: key N+1 is retired and key N+2 becomes the current key. (By 320 this time, key N+3 will have been published and be in the ready 321 state.) 323 The above illustrates one way of handling emergency keys. An equally 324 valid alternative would be to have a permanent emergency key. In 325 this scheme, a key is published in the zone as an emergency key: 326 unless it needs to be used in an emergency, it is never used to sign 327 the zone. Instead, active keys are replaced by their successors as 328 shown in Figure 1. 330 2.2.2. Emergency Key Use 332 An emergency key rollover could be required at any time. Referring 333 back to Figure 2, should an emergency rollover be required between 334 events 2 and 3, the sequence would happen as previously described: 335 there is a already key (key N+2) ready to take over as the emergency 336 key when the current emergency key becomes active. In the worst case 337 though, it may be required that the system run without an emergency 338 key for a while. For example, if a key rollover was required between 339 events 3 and 4 in Figure 2, the timeline would look like: 341 |3a| |3b| 342 | | 343 Key N+1 - --- Lz --->| | 344 | | 345 Key N+2 - ---------->|<----------Lz----- - - 346 | | 347 Key N+3 |<--Ip-->|<-------- - - 348 | | 350 ---- Time ----> 352 Timeline showing emergency key rollover. 354 Figure 3 356 In the above figure, the interval shown lies between events 3 and 4 357 in Figure 2, the events being labelled 3a and 3b to highlight this. 359 Here it is assumed that key N+1 is initially in the active state and 360 that the single emergency key (N+2) is in the ready state. It is 361 well before the active key's retire time, so there are only these two 362 ZSKs in the zone. The events are: 364 Event 3a: an emergency ZSK rollover is required. Key N+1 is retired 365 and key N+2 becomes active. At this time, key N+3 (which will 366 ultimately become the new emergency key) is published in the zone. 368 Event 3b: key N+3 moves into the ready state, after which it can be 369 used to replace key N+1 should the need arise. 371 Between events 3a and 3b however, only the active key (key N+2) can 372 be used to sign the zone. If a second emergency arises in this 373 interval, the active key cannot be replaced: key rollover must wait 374 until the new emergency key (N+3) becomes ready. Of course, this can 375 be mitigated by having a number of emergency keys available, but how 376 many is a matter of policy; there is a need to weigh the likelihood 377 of a key compromise against the number of keys required. 379 2.3. Key Rollover Logic 381 2.3.1. Actual and Estimated Times 383 In the above discussions, mention has been made of a number of 384 significant times in the life of a key, e.g. publication time, 385 activation time etc. At any particular time, the key is in one and 386 only one state. The time at which it entered that state (and the 387 time at which it entered all past states) are actual times. All 388 future times are estimated times. For example, although the retire 389 time of an active key is "activation time + key lifetime", until the 390 key actually makes the transition into the retired state (by no 391 longer being used to sign the zone), the retire time is only an 392 estimate of the retire time: it may change depending on events. 394 2.3.2. Practical Timing Considerations 396 Section Section 2.1 gave the theoretical timings for the entry of the 397 ZSK to different states. The most critical transitions are between 398 the publish and ready states, and between the retired and dead 399 states. In both cases, a premature transition could lead to 400 signatures not being validated. 402 Adding a safety margin is therefore prudent. Such a margin takes in 403 to account small uncertainties in timings as well as providing the 404 implementation with robustness. The former could be due to factors 405 such as the clocks on the server and validator running at slightly 406 different rates so leading to a discrepancy in the calculation of 407 intervals (interval skew). Adding robustness is just good management 408 practice: the calculations above show when the key should be in the 409 ready state - a safety margin provides increased certainty that all 410 parties agree that this is the case. 412 In practical terms, adding a safety margin means replacing Ip and It 413 in the equations above by Ip' and It' where: 415 Ip' = Ip + Sp 417 It' = It + St 419 Sp is the publish safety margin and St the retire safety margin. At 420 minimum they should be of the order of a few seconds to account for 421 the interval skew; in practice, they are likely to be much greater, 422 of the order of TTLsig. 424 2.3.3. ZSK Management Procedure 426 The following section describes the procedure for maintaining ZSKs. 427 It handles key rollover - both scheduled and emergency - as well as 428 flagging which keys should be published in preparation for use in 429 signing the zone. 431 The following is assumed: 433 1. Information about keys is held in some data store. The 434 information includes the state of each key and the times 435 associated with each state change for each key. 437 2. There is only one active ZSK at any one time. 439 3. The procedure is run on a regular basis (at intervals of Ir) that 440 depends on the interval between events in the timeline in 441 Figure 1. (This is discussed further below.) 443 In the following discussion, "now()" is the time at which the 444 procedure is run. Also defined is Nze as the number of emergency 445 ZKSs required to be able to immediately roll at any time for 446 emergency reasons. A likely value is: 448 Nze = 1 450 1. For all keys in the data store, calculate the estimated time of 451 entering the next stage using the relationships described above. 453 2. If this procedure is being run as part of an emergency rollover, 454 set the estimated retirement time for the active key(s) as now(). 455 (In this way, an emergency key rollover requires no special 456 processing: it is merely the early retirement of the active key.) 458 3. For each retired key, if now() >= Td, mark the key as dead. (Or 459 remove it from the data store. Either way, this key is no longer 460 of use and will never be used again.) 462 4. For each published key, if now() >= Tr, mark the key as ready. 464 5. If now() is within (Ip + Ir) of the estimated retire time of the 465 active key (Ir being the interval between runs of the procedure) 466 AND the number of keys in the publish and ready states combined 467 is less than (1 + Nze), move a number of keys equal to the 468 difference between these two values from the generate state into 469 the publish state. (This step ensures that when the active key 470 is retired, there is a key to replace it as well as the desired 471 number of emergency keys in the ready state.) 473 The term Ir appears here because to avoid a policy violation 474 (i.e. a delay in retiring the active key) this action must occur 475 at least Ip before the estimated retire time of the key. As the 476 procedure is run at intervals, the only way to guarantee this is 477 to add a margin equal to the run interval. 479 6. If now() is earlier than the retire time of the active key, exit. 480 (Note "earlier"; if an emergency rollover is taking place, the 481 retirement time of the active key will be equal to now() due to 482 the processing of step 2.) 484 7. Check whether there are keys in the ready state. If not, the 485 currently active key cannot be retired and the procedure will 486 have to wait until one or more keys become ready. In this case, 487 exit the procedure. 489 8. Mark the active key as retired. 491 9. Mark one of the ready keys as active. 493 After this procedure, all keys in the publish, ready, active and 494 retire states should be published in the zone. The active key should 495 be used to sign the zone. 497 3. Key-Signing Keys 499 3.1. Key Timeline 501 There are three significant differences between key-signing keys 502 (KSKs) and ZSKs: 504 1. KSKs only sign the DNSKEY RRset. This means that, unlike ZSKs, 505 it is feasible to use multiple KSKs to sign the zone without 506 generating a excessive amount of signature data. 508 2. They have to involve the parent zone in the addition and removal 509 of DS records. 511 3. KSKs may be configured as so-called "trust anchors" in validating 512 resolvers. Whether or not a KSK is used as a trust anchor and 513 how to transport the KSK to the validator in a secure way is 514 outside the scope of this document. 516 The first difference has led to the preferred method for handling KSK 517 rollover [RFC4641] being that of double-signature: the DNSKEY RRset 518 is signed by both the new key and the old key and the associated DS 519 records for both published in the parent zone. After a suitable 520 interval, the records for the old key are removed. This is the 521 scheme described in the timeline below. 523 The second difference means that timings are not wholly within the 524 control of the zone manager, in that the time take to publish the DS 525 records depends on the policies and procedures of the parent zone. A 526 further ramification is that the independence of the parent DS and 527 child DNSKEY records means that downstream validators might have 528 inconsistent data, i.e. the DS record without the DNSKEY record or 529 vice-versa. Although this is valid state according to [RFC4035], the 530 information cannot be used for validation until the validator has 531 both components. 533 |1| |2| |3| |4| |5| |6| |7| |8| 534 | | | | | | | | 535 Key N | |<-Ip->|<-->|<-------Lk------->|<------>| 536 | | | | | | | | 537 Key N+1 | | | | |<-Ip->|<--->|<---Lk--- - - 538 | | | | | | | | 539 Tg Tp Tr Ta Tps Tt Tm 541 ---- Time ----> 543 Timeline for a KSK rollover. 545 Figure 4 547 Event 1: key N is generated at time Tg and enters the generate state. 548 As before, although there is no reason why the key cannot be 549 generated immediately prior to publication, some implementations may 550 find its convenient to create a central pool of keys and draw from 551 it. For this reason, it is again shown as a separate event. 553 Event 2: the key is added to and used for signing the DNSKEY RRset 554 and is thereby published in the zone. At the same time, the 555 corresponding DS record is also submitted to the parent zone for 556 publication. This time is the publish time (Tp) and the KSK is said 557 to be in the published state. 559 Event 3: after some time (the publication interval, Ip), any 560 validator that has copies of the DNSKEY and/or DS RRsets in its cache 561 will have a copy of the data for key N. This point is the ready time 562 and is given by: 564 Tr = Tp + Ip 566 In the case of the KSK, the publication interval depends on the 567 publication interval of both the DNSKEY record and the DS record. 568 These are independent of one another, so a suitable expression for Ip 569 is: 571 Ip = max(Ipc, Ipp) 573 Ipc is the publication interval in the child zone and Ipp that of the 574 parent. 576 The child term comprises two parts - the time taken for the 577 introduction of the DNSKEY record to be registered on the downstream 578 slave servers (= Dpc, the child propagation delay) and the time taken 579 for information about the DNSKEY RRset to expire from the validator 580 cache, i.e. 582 Ipc = max(TTLkeyc, Cc) + Dpc 584 (TTLkeyc is the TTL for a DNSKEY record in the child zone and Cc the 585 negative cache time in that zone. The max() function occurs to 586 combine the separate expressions for the first and subsequent key in 587 a zone, as described in event 3 in section Section 2.1.) 589 The parent term is similar, but also includes the time taken for the 590 DS record to be included in the parent zone after the request has 591 been made. In other words: 593 Ipp = Dr + max(TTLdsp, Cp) + Dpp 595 (TTLdsp is the TTL for a DS record in the parent zone, Cp the 596 negative cache time in that zone, Dpp the propagation delay. Dr is 597 the registration delay, which is the time taken between the 598 submission of the DS record to the parent zone and its publication in 599 the zone.) 601 As the key has already been used to sign the DNSKEY RRset, the key is 602 also active, in that all other KSKs could be withdrawn from the zone 603 at this point and the zone would still be valid. However, while a 604 predecessor key is active, it is convenient to regard the successor 605 key as merely being ready. 607 Event 4: at some later time, the predecessor key is withdrawn from 608 the zone and, in the absence of any emergency keys, key N becomes the 609 only KSK for the zone. The key is said to be active, and this time 610 is the active time (Ta) 612 Event 5: as with the ZSK, at some point we need to give thought to 613 key replacement. The successor key must be introduced into the zone 614 at a time such that when the current key is withdrawn, any validator 615 that has key information (DNSKEY and/or DS records) in its cache will 616 have data about the successor key. 618 As before, this interval is the publication interval, Ip. Denoting 619 the publication time of the successor key as Tps, we get: 621 Tps <= Ta + Lk - Ip 623 Event 6: the successor key (key N+1) enters the ready state. 625 Event 7: at some time a decision will be made to retire the current 626 key (key N). This will be when the current key has been active for 627 its lifetime (Lk). At this point, the retire time, the successor key 628 becomes active and the current key is said to be retired: 630 Tt = Ta + Lk 632 Event 8: at some later time, the DNSKEY record can be removed from 633 the child zone and a request made to remove the DS record from the 634 parent zone. This is the removal time, Tm and is given by: 636 Tm >= Tt 638 Note the differences to a ZSK. In the case of a ZSK, only one key at 639 a time is used to sign the zone. Therefore, when the active ZSK is 640 retired, there may be copies of signatures created using it in the 641 caches of downstream validators. For this reason, a copy of the ZSK 642 has to be kept in the zone until all cached signatures haver expired. 644 With a KSK, both the active key and the successor key sign the DNSKEY 645 RRset. By the time the successor becomes active, any validator with 646 the DNSKEY RRset in its cache has a copy of the successor key. 647 Therefore as soon as the active key is retired, it can be removed 648 from the zone - there is no retire interval or dead time. (Although 649 for completeness, and in analogy with the ZSK, a dead time could be 650 defined by Td = Tm.) 652 3.2. Emergency Key-Signing Keys 654 In the same way that additional ZSKs are kept in a ready state in the 655 zone to act as emergency keys, additional KSKs need to be available 656 in the ready state for the same reason. The number of emergency keys 657 kept available is a matter of key management policy, and the logic 658 for the introduction of emergency keys into the zone is the same as 659 that given in Section 2.2.1. 661 3.3. Key Rollover 663 By definition, KSK rollovers have to involve the parent zone. If (as 664 is the usual case) the parent zone is managed by a different entity 665 then the timing of some of the steps in the KSK rollover operation 666 may be subject to uncertainty. In the above analysis, this has been 667 represented above by the DS registration delay (Dr); in practice, 668 confirmation needs to be sought that the step has successfully 669 completed. 671 It is important to note however, that this does not preclude the 672 development of key rollover logic similar to that described in 673 Section 2.3.3 for the ZSKs. In accordance with the goal of the 674 rollover logic being able to determine when a state change is "safe", 675 the only effect of being dependent on the parent is that there may be 676 a period waiting for the parent to respond, in addition to any 677 interval the key rollover logic requires. 679 Although this introduces additional delays, even with a parent that 680 is less than ideally responsive the only effect will be a slowdown in 681 the rollover state transitions. This may cause a policy violation, 682 but will not cause any operational problems. 684 3.4. Key Rollover Logic 686 3.4.1. Actual and Estimated Times 688 Time stamps for KSK rollovers exhibit the same behaviour as for ZSK 689 rollovers in that all times are estimates until after the event to 690 which they refer has occurred. 692 3.4.2. Practical Timing Considerations 694 For reasons given in section Section 2.3.2, it is prudent to include 695 a safety margin in the initial publication interval used in any 696 practical implementation of KSK timing, i.e. in the equations above 697 replace Ip by Ip' where: 699 Ip' = Ip + Sp 701 As before, Sp is the publication safety interval, with a minimum 702 value of the order of seconds, but a realistic value of the order of 703 TTLsig. 705 3.4.3. KSK Management Procedure 707 The following section describes the procedure for maintaining KSKs in 708 a zone. It handles key rollover - both scheduled and emergency - as 709 well as flagging which keys should be published in preparation for 710 use in signing the zone. The procedure is largely similar to that 711 used for ZSKs. 713 As before, it is assumed that data about keys is held in some key 714 management store, that the procedure is run on a regular basis and 715 that "now()" is the time at which the procedure is run. Also defined 716 is Nke as the number of emergency KSKs required to be able to 717 immediately roll at any time for emergency reasons. A likely value 718 is: 720 Nke = 1 722 1. For all keys in the data store, calculate the estimated time of 723 entering the next stage using the relationships described above. 725 2. If this procedure is being run as part of an emergency rollover, 726 set the estimated retirement time for the active key as now(). 727 (In this way, an emergency key rollover requires no special 728 processing: it is merely the early retirement of the active key.) 730 3. For each published key, if now() >= Tr, mark the key as ready. 732 4. If now() is within (Ip + Ir) of the estimated retire time of the 733 active key (where Ir is the interval between runs of the 734 procedure) AND the number of keys in the publish and ready states 735 combined is less than (1 + Nke), move a number of keys equal to 736 the difference between these two values from the generate state 737 into the publish state. (This step ensures that when the active 738 key is retired, there are keys available to take over from it.) 739 The term Ir appears here because to avoid a policy violation 740 (i.e. a delay in retiring the active key) this action must occur 741 at least Ip before the estimated retire time of the key. As the 742 procedure is run at intervals, the only way to guarantee this is 743 to add a margin equal to the run interval. 745 5. If now() is earlier than the retire time of the current key, exit 746 the procedure. (Note "earlier"; if an emergency rollover is 747 taking place, the retirement time of the active key will be equal 748 to now() due to the processing of step 2.) 750 6. Check whether there are keys in the ready state. If not, the 751 currently active key cannot be retired and the procedure will 752 have to wait until one or more keys become ready. In this case, 753 exit the procedure. 755 7. Check that the DS record of the successor key is available from 756 the parent zone. (The check may be made in a variety of ways, 757 including querying one of or all of the parent nameservers, or 758 just querying the server furthest down the chain of parent 759 nameservers.) If the record is not available, exit the 760 procedure. 762 The key that will replace the active key is in the ready state. 763 However, the entry to the ready state is based on the assumption 764 that the DS record has been published after a time Dr. But that 765 is only an assumption, and relies on the behaviour of the parent 766 zone operator. To be safe, a check is made that the DS record 767 has propagated through the parent's server network. If it 768 hasn't, there may have been some breakdown in communication with 769 the parent zone. 771 8. Mark the active key as retired. 773 9. Mark the successor key as active. 775 After this procedure, all keys in the publish, ready and active 776 states should be published in the zone. Retired keys may be removed 777 from the zone when convenient. 779 4. Running the Key Management Procedures 781 The preceding sections outlined procedures to be used to manage KSKs 782 and ZSKs. One way to use these procedures is to run them only when a 783 significant event occurs. In other words, when a procedure 784 completes, calculate the time at which the next event will occur and 785 run it again at that time. 787 In practice though (and what has been assumed in the management 788 procedures outlined above), it will be easier to run them on a 789 regular basis. This has two implications: 791 1. Depending on the frequency of running the procedure, in many 792 cases the result will be a no-op; the set of keys to be published 793 in the zone will be unchanged from the last time it is run. 795 2. Policy will not be enforced exactly, e.g. the a key may remain 796 active longer that the key lifetime because the procedure is not 797 run until some time after the retire time of the active key is 798 reached. 800 Neither of these objections is fatal. In the first case, it will be 801 easy to detect that a key set is unchanged and so prevent a needless 802 update. The latter case is dealt with by reducing the run interval 803 to the point at which the maximum delay in making a transition 804 between the states of keys is acceptable. 806 5. IANA Considerations 808 This memo includes no request to IANA. 810 6. Security Considerations 812 This document does not introduce any new security issues beyond those 813 already discussed in [RFC4033], [RFC4034] and [RFC4035]. 815 7. Acknowledgements 817 The authors gratefully acknowledge help and contributions from Roy 818 Arends and Wouter Wijngaards. 820 8. Normative References 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, March 1997. 825 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 826 NCACHE)", RFC 2308, March 1998. 828 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 829 Rose, "DNS Security Introduction and Requirements", 830 RFC 4033, March 2005. 832 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 833 Rose, "Resource Records for the DNS Security Extensions", 834 RFC 4034, March 2005. 836 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 837 Rose, "Protocol Modifications for the DNS Security 838 Extensions", RFC 4035, March 2005. 840 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 841 RFC 4641, September 2006. 843 Appendix A. List of Symbols 845 The following symbols have been used in the text: 847 C Negative cache time. 849 Cc Negative cache time in the child zone. 851 Cp Negative cache time in the parent zone. 853 Dp Propagation delay. The amount of time for a change made at 854 a master nameserver to propagate to all the slave 855 nameservers. 857 Dpc Propagation delay in the child zone. 859 Dpp Propagation delay in the parent zone. 861 Dr Registration delay, the time between submission of a DS 862 record to the parent zone and its publication in the zone. 864 Ip Publication interval. The amount of time that must elapse 865 after the publication of a key before it can be considered 866 to have entered the ready state. 868 Ip' Publication interval taking into account a safety margin. 870 Ipc Publication interval for the child zone. 872 Ipp Publication interval for the parent zone. 874 Ir Run interval. The time between successive runs of the key 875 rollover procedure. 877 It Retire interval. The amount of time that must elapse after 878 a key enters the retire state for any signatures created 879 with it to be purged from validator caches. 881 It' Retire interval taking into account a safety margin. 883 Lk Lifetime of a key-signing key. This is the intended amount 884 of time for which this particular KSK is regarded as the 885 active KSK. Depending on when the key is rolled-over, the 886 actual lifetime may be longer or shorter than this. 888 Lz Lifetime of a zone-signing key. This is the intended 889 amount of time for which the ZSK is used to sign the zone. 890 Depending on when the key is rolled-over, the actual 891 lifetime may be longer or shorter than this. 893 Nke Number of emergency KSKs in a zone. 895 Nze Number of emergency ZSKs in a zone. 897 SOAmin The value of the "minimum" parameter in the zone's SOA 898 record. 900 Sp Publish safety margin. An interval of time used to 901 guarantee that a key is truly in the ready state. 903 St Retire safety margin. An interval of time used to 904 guarantee that a key is truly in the dead state. 906 Ta Active time of the key. For a ZSK, the time that they key 907 is first used to sign the zone. For a KSK, the time at 908 which this key is regarded as being the principal KSK for 909 the zone. 911 Td Dead time of a key. Applicable only to ZSKs, this is the 912 time at which any record signatures held in validator 913 caches are guaranteed to be created with the successor key. 915 Tg Generate time of a key. The time that a key is created. 917 Tm Removal time of a key. The time at which a key is removed 918 from the zone. 920 Tp Publish time of a key. The time that a key appears in a 921 zone for the first time. 923 Tps Publish time of the successor key. 925 Tr Ready time of a key. The time at which it can be 926 guaranteed that a validators that have key information from 927 this zone cached have a copy of this key in their cache. 928 (In the case of KSKs, should the validators also have DS 929 information from the parent zone cached, the cache must 930 include information about the DS record corresponding to 931 the key.) 933 Tt Retire time of a key. The time at which a successor key 934 starts being used to sign the zone. 936 TTLdsp Time to live of a DS record in the parent zone. 938 TTLkey Time to live of a DNSKEY record. 940 TTLkeyc Time to live of a DNSKEY record in the child zone. 942 TTLsoa Time to live of a SOA record. 944 TTLsig Time to live of a RRSIG record. 946 Authors' Addresses 948 Stephen Morris 949 Nominet 950 Minerva House, Edmund Halley Road 951 Oxford, OX4 4DQ 952 UK 954 Phone: +44 1865 332211 955 Email: stephen@nominet.org.uk 957 Johan Ihren 958 Autonomica 959 Bellmansgatan 30 960 Stockholm, SE-118 47 961 Sweden 963 Phone: +46 8615 8573 964 Email: johani@autonomica.se 965 John Dickinson 966 6 Nelson Close 967 Wallingford, OX10 0LG 968 UK 970 Phone: 971 Email: jad@jadickinson.co.uk