1 Internet Engineering Task Force (IETF) S. Morris
2 Request for Comments: 7583 ISC
3 Category: Informational J. Ihren
4 ISSN: 2070-1721 Netnod
5 J. Dickinson
6 Sinodun
7 W. Mekking
8 Dyn
9 October 2015
10
11
12 DNSSEC Key Rollover Timing Considerations
13
14 Abstract
15
16 This document describes the issues surrounding the timing of events
17 in the rolling of a key in a DNSSEC-secured zone. It presents
18 timelines for the key rollover and explicitly identifies the
19 relationships between the various parameters affecting the process.
20
21 Status of This Memo
22
23 This document is not an Internet Standards Track specification; it is
24 published for informational purposes.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Not all documents
30 approved by the IESG are a candidate for any level of Internet
31 Standard; see Section 2 of RFC 5741.
32
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 http://www.rfc-editor.org/info/rfc7583.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Morris, et al. Informational [Page 1]
53 RFC 7583 Key Timing October 2015
54
55
56 Copyright Notice
57
58 Copyright (c) 2015 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction ....................................................3
74 1.1. Key Rolling Considerations .................................3
75 1.2. Types of Keys ..............................................4
76 1.3. Terminology ................................................4
77 1.4. Limitation of Scope ........................................5
78 2. Rollover Methods ................................................5
79 2.1. ZSK Rollovers ..............................................5
80 2.2. KSK Rollovers ..............................................7
81 3. Key Rollover Timelines ..........................................8
82 3.1. Key States .................................................8
83 3.2. ZSK Rollover Timelines ....................................10
84 3.2.1. Pre-Publication Method .............................10
85 3.2.2. Double-Signature Method ............................12
86 3.3. KSK Rollover Timelines ....................................14
87 3.3.1. Double-KSK Method ..................................14
88 3.3.2. Double-DS Method ...................................17
89 3.3.3. Double-RRset Method ................................20
90 3.3.4. Interaction with Configured Trust Anchors ..........22
91 3.3.5. Introduction of First Keys .........................24
92 4. Standby Keys ...................................................24
93 5. Algorithm Considerations .......................................25
94 6. Summary ........................................................26
95 7. Security Considerations ........................................26
96 8. Normative References ...........................................26
97 Appendix A. List of Symbols ......................................28
98 Acknowledgements ..................................................31
99 Authors' Addresses ................................................31
100
101
102
103
104
105
106
107 Morris, et al. Informational [Page 2]
108 RFC 7583 Key Timing October 2015
109
110
111 1. Introduction
112
113 1.1. Key Rolling Considerations
114
115 When a zone is secured with DNSSEC, the zone manager must be prepared
116 to replace ("roll") the keys used in the signing process. The
117 rolling of keys may be caused by compromise of one or more of the
118 existing keys, or it may be due to a management policy that demands
119 periodic key replacement for security or operational reasons. In
120 order to implement a key rollover, the keys need to be introduced
121 into and removed from the zone at the appropriate times.
122 Considerations that must be taken into account are:
123
124 o DNSKEY records and associated information (such as the DS records
125 or RRSIG records created with the key) are not only held at the
126 authoritative nameserver, they are also cached by resolvers. The
127 data on these systems can be interlinked, e.g., a validating
128 resolver may try to validate a signature retrieved from a cache
129 with a key obtained separately.
130
131 o Zone "bootstrapping" events, where a zone is signed for the first
132 time, can be common in configurations where a large number of
133 zones are being served. Procedures should be able to cope with
134 the introduction of keys into the zone for the first time as well
135 as "steady-state", where the records are being replaced as part of
136 normal zone maintenance.
137
138 o To allow for an emergency re-signing of the zone as soon as
139 possible after a key compromise has been detected, standby keys
140 (additional keys over and above those used to sign the zone) need
141 to be present.
142
143 o A query for the DNSKEY RRset returns all DNSKEY records in the
144 zone. As there is limited space in the UDP packet (even with
145 EDNS0 support), key records no longer needed must be periodically
146 removed. (For the same reason, the number of standby keys in the
147 zone should be restricted to the minimum required to support the
148 key management policy.)
149
150 Management policy, e.g., how long a key is used for, also needs to be
151 considered. However, the point of key management logic is not to
152 ensure that a rollover is completed at a certain time but rather to
153 ensure that no changes are made to the state of keys published in the
154 zone until it is "safe" to do so ("safe" in this context meaning that
155 at no time during the rollover process does any part of the zone ever
156 go bogus). In other words, although key management logic enforces
157 policy, it may not enforce it strictly.
158
159
160
161
162 Morris, et al. Informational [Page 3]
163 RFC 7583 Key Timing October 2015
164
165
166 A high-level overview of key rollover can be found in [RFC6781]. In
167 contrast, this document focuses on the low-level timing detail of two
168 classes of operations described there, the rollover of Zone Signing
169 Keys (ZSKs), and the rollover of Key Signing Keys (KSKs).
170
171 Note that the process for the introduction of keys into a zone is
172 different from that of rolling a key; see Section 3.3.5 for more
173 information.
174
175 1.2. Types of Keys
176
177 Although DNSSEC validation treats all keys equally, [RFC4033]
178 recognizes the broad classification of ZSKs and KSKs. A ZSK is used
179 to authenticate information within the zone; a KSK is used to
180 authenticate the zone's DNSKEY RRset. The main implication for this
181 distinction concerns the consistency of information during a
182 rollover.
183
184 During operation, a validating resolver must use separate pieces of
185 information to perform an authentication. At the time of
186 authentication, each piece of information may be in its cache or may
187 need to be retrieved from an authoritative server. The rollover
188 process needs to happen in such a way that the information is
189 consistent at all times during the rollover. With a ZSK, the
190 information is the RRSIG (plus associated RRset) and the DNSKEY.
191 These are both obtained from the same zone. In the case of the KSK,
192 the information is the DNSKEY and DS RRset with the latter being
193 obtained from a different zone.
194
195 Although there are similarities in the algorithms to roll ZSKs and
196 KSKs, there are a number of differences. For this reason, the two
197 types of rollovers are described separately.
198
199 1.3. Terminology
200
201 The terminology used in this document is as defined in [RFC4033] and
202 [RFC5011].
203
204 A number of symbols are used to identify times, intervals, etc. All
205 are listed in Appendix A.
206
207
208
209
210
211
212
213
214
215
216
217 Morris, et al. Informational [Page 4]
218 RFC 7583 Key Timing October 2015
219
220
221 1.4. Limitation of Scope
222
223 This document represents current thinking at the time of publication.
224 However, the subject matter is evolving and it is not possible for
225 the document to be comprehensive. In particular, it does not cover:
226
227 o Rolling a key that is used as both a ZSK and KSK.
228
229 o Algorithm rollovers. Only the rolling of keys of the same
230 algorithm is described here: not transitions between algorithms.
231
232 o Changing TTLs.
233
234 Algorithm rollover is excluded from the document owing to the need
235 for there to be an RRSIG for at least one DNSKEY of each algorithm in
236 the DNSKEY RRset [RFC4035]. This introduces additional constraints
237 on rollovers that are not considered here. Such considerations do
238 not apply where other properties of the key, such as key length, are
239 changed during the rollover: the DNSSEC protocol does not impose any
240 restrictions in these cases.
241
242 Also excluded from consideration is the effect of changing the Time
243 to Live (TTL) of records in a zone. TTLs can be changed at any time,
244 but doing so around the time of a key rollover may have an impact on
245 event timings. In the timelines below, it is assumed that TTLs are
246 constant.
247
248 2. Rollover Methods
249
250 2.1. ZSK Rollovers
251
252 For ZSKs, the issue for the zone operator/signer is to ensure that
253 any caching validator that has access to a particular signature also
254 has access to the corresponding valid ZSK.
255
256 A ZSK can be rolled in one of three ways:
257
258 o Pre-Publication: described in [RFC6781], the new key is introduced
259 into the DNSKEY RRset, which is then re-signed. This state of
260 affairs remains in place for long enough to ensure that any cached
261 DNSKEY RRsets contain both keys. At that point, signatures
262 created with the old key can be replaced by those created with the
263 new key. During the re-signing process (which may or may not be
264 atomic depending on how the zone is managed), it doesn't matter
265 with which key an RRSIG record retrieved by a resolver was
266 created; cached copies of the DNSKEY RRset will contain both the
267 old and new keys.
268
269
270
271
272 Morris, et al. Informational [Page 5]
273 RFC 7583 Key Timing October 2015
274
275
276 Once the zone contains only signatures created with the new key,
277 there is an interval during which RRSIG records created with the
278 old key expire from caches. After this, there will be no
279 signatures anywhere that were created using the old key, and it
280 can be removed from the DNSKEY RRset.
281
282 o Double-Signature: also mentioned in [RFC6781], this involves
283 introducing the new key into the zone and using it to create
284 additional RRSIG records; the old key and existing RRSIG records
285 are retained. During the period in which the zone is being signed
286 (again, the signing process may not be atomic), validating
287 resolvers are always able to validate RRSIGs: any combination of
288 old and new DNSKEY RRset and RRSIGs allows at least one signature
289 to be validated.
290
291 Once the signing process is complete and enough time has elapsed
292 to make sure that all validators that have the DNSKEY and
293 signatures in cache have both the old and new information, the old
294 key and signatures can be removed from the zone. As before,
295 during this period any combination of DNSKEY RRset and RRSIGs will
296 allow validation of at least one signature.
297
298 o Double-RRSIG: strictly speaking, the use of the term "Double-
299 Signature" above is a misnomer as the method is not only double
300 signature, it is also double key as well. A true Double-Signature
301 method (here called the Double-RRSIG method) involves introducing
302 new signatures in the zone (while still retaining the old ones)
303 but not introducing the new key.
304
305 Once the signing process is complete and enough time has elapsed
306 to ensure that all caches that may contain an RR and associated
307 RRSIG have a copy of both signatures, the key is changed. After a
308 further interval during which the old DNSKEY RRset expires from
309 caches, the old signatures are removed from the zone.
310
311 Of the three methods, Double-Signature is conceptually the simplest:
312 introduce the new key and new signatures, then approximately one TTL
313 later remove the old key and old signatures. It is also the fastest,
314 but suffers from increasing the size of the zone and the size of
315 responses.
316
317 Pre-Publication is more complex: introduce the new key, approximately
318 one TTL later sign the records, and approximately one TTL after that
319 remove the old key. It does however keep the zone and response sizes
320 to a minimum.
321
322
323
324
325
326
327 Morris, et al. Informational [Page 6]
328 RFC 7583 Key Timing October 2015
329
330
331 Double-RRSIG is essentially the reverse of Pre-Publication: introduce
332 the new signatures, approximately one TTL later change the key, and
333 approximately one TTL after that remove the old signatures. However,
334 it has the disadvantage of the Pre-Publication method in terms of
335 time taken to perform the rollover, the disadvantage of the Double-
336 Signature rollover in terms of zone and response sizes, and none of
337 the advantages of either. For these reasons, it is unlikely to be
338 used in any real-world situations and so will not be considered
339 further in this document.
340
341 2.2. KSK Rollovers
342
343 In the KSK case, there should be no problem with a caching validator
344 not having access to a signature created with a valid KSK. The KSK
345 is only used for one signature (that over the DNSKEY RRset) and both
346 the key and the signature travel together. Instead, the issue is to
347 ensure that the KSK is trusted.
348
349 Trust in the KSK is due to either the existence of a signed and
350 validated DS record in the parent zone or an explicitly configured
351 trust anchor. If the former, the rollover algorithm will need to
352 involve the parent zone in the addition and removal of DS records, so
353 timings are not wholly under the control of the zone manager. If the
354 latter, [RFC5011] timings will be needed to roll the keys. (Even in
355 the case where authentication is via a DS record, the zone manager
356 may elect to include [RFC5011] timings in the key rolling process so
357 as to cope with the possibility that the key has also been explicitly
358 configured as a trust anchor.)
359
360 It is important to note that the need to interact with the parent
361 does not preclude the development of key rollover logic; in
362 accordance with the goal of the rollover logic, being able to
363 determine when a state change is "safe", the only effect of being
364 dependent on the parent is that there may be a period of waiting for
365 the parent to respond in addition to any delay the key rollover logic
366 requires. Although this introduces additional delays, even with a
367 parent that is less than ideally responsive, the only effect will be
368 a slowdown in the rollover state transitions. This may cause a
369 policy violation, but will not cause any operational problems.
370
371 Like the ZSK case, there are three methods for rolling a KSK:
372
373 o Double-KSK: the new KSK is added to the DNSKEY RRset, which is
374 then signed with both the old and new key. After waiting for the
375 old RRset to expire from caches, the DS record in the parent zone
376 is changed. After waiting a further interval for this change to
377 be reflected in caches, the old key is removed from the RRset.
378
379
380
381
382 Morris, et al. Informational [Page 7]
383 RFC 7583 Key Timing October 2015
384
385
386 o Double-DS: the new DS record is published. After waiting for this
387 change to propagate into caches, the KSK is changed. After a
388 further interval during which the old DNSKEY RRset expires from
389 caches, the old DS record is removed.
390
391 o Double-RRset: the new KSK is added to the DNSKEY RRset, which is
392 then signed with both the old and new key, and the new DS record
393 is added to the parent zone. After waiting a suitable interval
394 for the old DS and DNSKEY RRsets to expire from caches, the old
395 DNSKEY and DS records are removed.
396
397 In essence, Double-KSK means that the new KSK is introduced first and
398 used to sign the DNSKEY RRset. The DS record is changed, and finally
399 the old KSK is removed. It limits interactions with the parent to a
400 minimum but, for the duration of the rollover, the size of the DNSKEY
401 RRset is increased.
402
403 With Double-DS, the order of operations is the other way around:
404 introduce the new DS, change the DNSKEY, then remove the old DS. The
405 size of the DNSKEY RRset is kept to a minimum, but two interactions
406 are required with the parent.
407
408 Finally, Double-RRset is the fastest way to roll the KSK, but has the
409 drawbacks of both of the other methods: a larger DNSKEY RRset and two
410 interactions with the parent.
411
412 3. Key Rollover Timelines
413
414 3.1. Key States
415
416 DNSSEC validation requires both the DNSKEY and information created
417 from it (referred to as "associated data" in this section). In the
418 case of validation of an RR, the data associated with the key is the
419 corresponding RRSIG. Where there is a need to validate a chain of
420 trust, the associated data is the DS record.
421
422 During the rolling process, keys move through different states. The
423 defined states are:
424
425 Generated Although keys may be created immediately prior to first
426 use, some implementations may find it convenient to
427 create a pool of keys in one operation and draw from it
428 as required. (Note: such a pre-generated pool must be
429 secured against surreptitious use.) In the timelines
430 below, before the first event, the keys are considered to
431 be created but not yet used: they are said to be in the
432 "Generated" state.
433
434
435
436
437 Morris, et al. Informational [Page 8]
438 RFC 7583 Key Timing October 2015
439
440
441 Published A key enters the published state when either it or its
442 associated data first appears in the appropriate zone.
443
444 Ready The DNSKEY or its associated data have been published for
445 long enough to guarantee that copies of the key(s) it is
446 replacing (or associated data related to that key) have
447 expired from caches.
448
449 Active The data is starting to be used for validation. In the
450 case of a ZSK, it means that the key is now being used to
451 sign RRsets and that both it and the created RRSIGs
452 appear in the zone. In the case of a KSK, it means that
453 it is possible to use it to validate a DNSKEY RRset as
454 both the DNSKEY and DS records are present in their
455 respective zones. Note that when this state is entered,
456 it may not be possible for validating resolvers to use
457 the data for validation in all cases: the zone signing
458 may not have finished or the data might not have reached
459 the resolver because of propagation delays and/or caching
460 issues. If this is the case, the resolver will have to
461 rely on the predecessor data instead.
462
463 Retired The data has ceased to be used for validation. In the
464 case of a ZSK, it means that the key is no longer used to
465 sign RRsets. In the case of a KSK, it means that the
466 successor DNSKEY and DS records are in place. In both
467 cases, the key (and its associated data) can be removed
468 as soon as it is safe to do so, i.e., when all validating
469 resolvers are able to use the new key and associated data
470 to validate the zone. However, until this happens, the
471 current key and associated data must remain in their
472 respective zones.
473
474 Dead The key and its associated data are present in their
475 respective zones, but there is no longer information
476 anywhere that requires their presence for use in
477 validation. Hence, they can be removed at any time.
478
479 Removed Both the DNSKEY and its associated data have been removed
480 from their respective zones.
481
482 Revoked The DNSKEY is published for a period with the "revoke"
483 bit set as a way of notifying validating resolvers that
484 have configured it as a trust anchor, as used in
485 [RFC5011], that it is about to be removed from the zone.
486 This state is used when [RFC5011] considerations are in
487 effect (see Section 3.3.4).
488
489
490
491
492 Morris, et al. Informational [Page 9]
493 RFC 7583 Key Timing October 2015
494
495
496 3.2. ZSK Rollover Timelines
497
498 The following sections describe the rolling of a ZSK. They show the
499 events in the lifetime of a key (referred to as "key N") and cover
500 its replacement by its successor (key N+1).
501
502 3.2.1. Pre-Publication Method
503
504 In this method, the new key is introduced into the DNSKEY RRset.
505 After enough time to ensure that any cached DNSKEY RRsets contain
506 both keys, the zone is signed using the new key and the old
507 signatures are removed. Finally, when all signatures created with
508 the old key have expired from caches, the old key is removed.
509
510 The following diagram shows the timeline of a Pre-Publication
511 rollover. Time increases along the horizontal scale from left to
512 right and the vertical lines indicate events in the process.
513 Significant times and time intervals are marked.
514
515 |1| |2| |3| |4| |5| |6| |7| |8|
516 | | | | | | | |
517 Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->|
518 | | | | | | | |
519 Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - -
520 | | | | | | | |
521 Key N Tpub Trdy Tact Tret Tdea Trem
522 Key N+1 Tpub Trdy Tact
523
524 ---- Time ---->
525
526 Figure 1: Timeline for a Pre-Publication ZSK Rollover
527
528 Event 1: Key N's DNSKEY record is put into the zone, i.e., it is
529 added to the DNSKEY RRset, which is then re-signed with the currently
530 active KSKs. The time at which this occurs is the publication time
531 (Tpub), and the key is now said to be published. Note that the key
532 is not yet used to sign records.
533
534 Event 2: Before it can be used, the key must be published for long
535 enough to guarantee that any cached version of the zone's DNSKEY
536 RRset includes this key.
537
538 This interval is the publication interval (Ipub) and, for the second
539 or subsequent keys in the zone, is given by:
540
541 Ipub = Dprp + TTLkey
542
543
544
545
546
547 Morris, et al. Informational [Page 10]
548 RFC 7583 Key Timing October 2015
549
550
551 Here, Dprp is the propagation delay -- the time taken for a change
552 introduced at the master to replicate to all nameservers. TTLkey is
553 the TTL for the DNSKEY records in the zone. The sum is therefore the
554 maximum time taken for existing DNSKEY records to expire from caches,
555 regardless of the nameserver from which they were retrieved.
556
557 (The case of introducing the first ZSK into the zone is discussed in
558 Section 3.3.5.)
559
560 After a delay of Ipub, the key is said to be ready and could be used
561 to sign records. The time at which this event occurs is key N's
562 ready time (Trdy), which is given by:
563
564 Trdy(N) = Tpub(N) + Ipub
565
566 Event 3: At some later time, the key starts being used to sign
567 RRsets. This point is the activation time (Tact) and after this, key
568 N is said to be active.
569
570 Tact(N) >= Trdy(N)
571
572 Event 4: At some point thought must be given to its successor (key
573 N+1). As with the introduction of the currently active key into the
574 zone, the successor key will need to be published at least Ipub
575 before it is activated. The publication time of key N+1 depends on
576 the activation time of key N:
577
578 Tpub(N+1) <= Tact(N) + Lzsk - Ipub
579
580 Here, Lzsk is the length of time for which a ZSK will be used (the
581 ZSK lifetime). It should be noted that in the diagrams, the actual
582 key lifetime is represented; this may differ slightly from the
583 intended lifetime set by key management policy.
584
585 Event 5: While key N is still active, its successor becomes ready.
586 From this time onwards, key N+1 could be used to sign the zone.
587
588 Event 6: When key N has been in use for an interval equal to the ZSK
589 lifetime, it is retired (i.e., it will never again be used to
590 generate new signatures) and key N+1 activated and used to sign the
591 zone. This is the retire time of key N (Tret), and is given by:
592
593 Tret(N) = Tact(N) + Lzsk
594
595 It is also the activation time of the successor key N+1. Note that
596 operational considerations may cause key N to remain in use for a
597 longer (or shorter) time than the lifetime set by the key management
598 policy.
599
600
601
602 Morris, et al. Informational [Page 11]
603 RFC 7583 Key Timing October 2015
604
605
606 Event 7: The retired key needs to be retained in the zone whilst any
607 RRSIG records created using this key are still published in the zone
608 or held in caches. (It is possible that a validating resolver could
609 have an old RRSIG record in the cache, but the old DNSKEY RRset has
610 expired when it is asked to provide both to a client. In this case
611 the DNSKEY RRset would need to be looked up again.) This means that
612 once the key is no longer used to sign records, it should be retained
613 in the zone for at least the retire interval (Iret) given by:
614
615 Iret = Dsgn + Dprp + TTLsig
616
617 Dsgn is the delay needed to ensure that all existing RRsets have been
618 re-signed with the new key. Dprp is the propagation delay, required
619 to guarantee that the updated zone information has reached all slave
620 servers, and TTLsig is the maximum TTL of all the RRSIG records in
621 the zone created with the retiring key.
622
623 The time at which all RRSIG records created with this key have
624 expired from resolver caches is the dead time (Tdea), given by:
625
626 Tdea(N) = Tret(N) + Iret
627
628 ... at which point the key is said to be dead.
629
630 Event 8: At any time after the key becomes dead, it can be removed
631 from the zone's DNSKEY RRset, which must then be re-signed with the
632 current KSK. This time is the removal time (Trem), given by:
633
634 Trem(N) >= Tdea(N)
635
636 ... at which time the key is said to be removed.
637
638 3.2.2. Double-Signature Method
639
640 In this rollover, a new key is introduced and used to sign the zone;
641 the old key and signatures are retained. Once all cached DNSKEY and/
642 or RRSIG information contains copies of the new DNSKEY and RRSIGs
643 created with it, the old DNSKEY and RRSIGs can be removed from the
644 zone.
645
646 The timeline for a Double-Signature rollover is shown below. The
647 diagram follows the convention described in Section 3.2.1.
648
649
650
651
652
653
654
655
656
657 Morris, et al. Informational [Page 12]
658 RFC 7583 Key Timing October 2015
659
660
661 |1| |2| |3| |4|
662 | | | |
663 Key N |<-------Lzsk----------->|<--->|
664 | | | |
665 | |<--Iret-->| |
666 | | | |
667 Key N+1 | |<----Lzsk------- - -
668 | | | |
669 Key N Tact Tdea Trem
670 Key N+1 Tact
671
672 ---- Time ---->
673
674 Figure 2: Timeline for a Double-Signature ZSK Rollover
675
676 Event 1: Key N is added to the DNSKEY RRset and is then used to sign
677 the zone; existing signatures in the zone are not removed. The key
678 is published and active: this is key N's activation time (Tact),
679 after which the key is said to be active.
680
681 Event 2: As the current key (key N) approaches the end of its actual
682 lifetime (Lzsk), the successor key (key N+1) is introduced into the
683 zone and starts being used to sign RRsets: neither the current key
684 nor the signatures created with it are removed. The successor key is
685 now also active.
686
687 Tact(N+1) = Tact(N) + Lzsk - Iret
688
689 Event 3: Before key N can be withdrawn from the zone, all RRsets that
690 need to be signed must have been signed by the successor key (key
691 N+1) and any old RRsets that do not include the new key or new RRSIGs
692 must have expired from caches. Note that the signatures are not
693 replaced: each RRset is signed by both the old and new key.
694
695 This takes Iret, the retire interval, given by the expression:
696
697 Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
698
699 As before, Dsgn is the delay needed to ensure that all existing
700 RRsets have been signed with the new key and Dprp is the propagation
701 delay, required to guarantee that the updated zone information has
702 reached all slave servers. The final term (the maximum of TTLkey and
703 TTLsig) is the period to wait for key and signature data associated
704 with key N to expire from caches. (TTLkey is the TTL of the DNSKEY
705 RRset and TTLsig is the maximum TTL of all the RRSIG records in the
706 zone created with the ZSK. The two may be different: although the
707
708
709
710
711
712 Morris, et al. Informational [Page 13]
713 RFC 7583 Key Timing October 2015
714
715
716 TTL of an RRSIG is equal to the TTL of the RRs in the associated
717 RRset [RFC4034], the DNSKEY RRset only needs to be signed with the
718 KSK.)
719
720 At the end of this interval, key N is said to be dead. This occurs
721 at the dead time (Tdea) so:
722
723 Tdea(N) = Tact(N+1) + Iret
724
725 Event 4: At some later time, key N and the signatures generated with
726 it can be removed from the zone. This is the removal time (Trem),
727 given by:
728
729 Trem(N) >= Tdea(N)
730
731 3.3. KSK Rollover Timelines
732
733 The following sections describe the rolling of a KSK. They show the
734 events in the lifetime of a key (referred to as "key N") and cover it
735 replacement by its successor (key N+1). (The case of introducing the
736 first KSK into the zone is discussed in Section 3.3.5.)
737
738 3.3.1. Double-KSK Method
739
740 In this rollover, the new DNSKEY is added to the zone. After an
741 interval long enough to guarantee that any cached DNSKEY RRsets
742 contain the new DNSKEY, the DS record in the parent zone is changed.
743 After a further interval to allow the old DS record to expire from
744 caches, the old DNSKEY is removed from the zone.
745
746 The timeline for a Double-KSK rollover is shown below. The diagram
747 follows the convention described in Section 3.2.1.
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767 Morris, et al. Informational [Page 14]
768 RFC 7583 Key Timing October 2015
769
770
771 |1| |2| |3| |4|
772 | | | |
773 Key N |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - -
774 | | | |
775 Key N+1 | | | |
776 | | | |
777 Key N Tpub Trdy Tsbm Tact
778 Key N+1
779
780 ---- Time ---->
781
782 (continued ...)
783
784 |5| |6| |7| |8| |9| |10|
785 | | | | | |
786 Key N - - --------------Lksk------->|<-Iret->|<----->|
787 | | | | | |
788 Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - -
789 | | | | | |
790 Key N Tret Tdea Trem
791 Key N+1 Tpub Trdy Tsbm Tact
792
793 ---- Time (cont.) ---->
794
795 Figure 3: Timeline for a Double-KSK Rollover
796
797 Event 1: Key N is introduced into the zone; it is added to the DNSKEY
798 RRset, which is then signed by all currently active KSKs. (So at
799 this point, the DNSKEY RRset is signed by both key N and its
800 predecessor KSK. If other KSKs were active, it is signed by these as
801 well.) This is the publication time of key N (Tpub); after this, the
802 key is said to be published.
803
804 Event 2: Before it can be used, the key must be published for long
805 enough to guarantee that any validating resolver that has a copy of
806 the DNSKEY RRset in its cache will have a copy of the RRset that
807 includes this key: in other words, that any prior cached information
808 about the DNSKEY RRset has expired.
809
810 The interval is the publication interval in the child zone (IpubC)
811 and is given by:
812
813 IpubC = DprpC + TTLkey
814
815
816
817
818
819
820
821
822 Morris, et al. Informational [Page 15]
823 RFC 7583 Key Timing October 2015
824
825
826 ... where DprpC is the propagation delay for the child zone (the zone
827 containing the KSK being rolled) and TTLkey the TTL for the DNSKEY
828 RRset. The time at which this occurs is the key N's ready time,
829 Trdy, given by:
830
831 Trdy(N) = Tpub(N) + IpubC
832
833 Event 3: At some later time, the DS record corresponding to the new
834 KSK is submitted to the parent zone for publication. This time is
835 the submission time, Tsbm:
836
837 Tsbm(N) >= Trdy(N)
838
839 Event 4: The DS record is published in the parent zone. As this is
840 the point at which all information for authentication -- both DNSKEY
841 and DS record -- is available in the two zones, in analogy with other
842 rollover methods, this is called the activation time of key N (Tact):
843
844 Tact(N) = Tsbm(N) + Dreg
845
846 ... where Dreg is the registration delay, the time taken after the DS
847 record has been submitted to the parent zone manager for it to be
848 placed in the zone. (Parent zones are often managed by different
849 entities, and this term accounts for the organizational overhead of
850 transferring a record. In practice, Dreg will not be a fixed time:
851 instead, the end of Dreg will be signaled by the appearance of the DS
852 record in the parent zone.)
853
854 Event 5: While key N is active, thought needs to be given to its
855 successor (key N+1). At some time before the scheduled end of the
856 KSK lifetime, the successor KSK is published in the zone. (As
857 before, this means that the DNSKEY RRset is signed by all KSKs.)
858 This time is the publication time of the successor key N+1, given by:
859
860 Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC
861
862 ... where Lksk is the actual lifetime of the KSK, and Dreg the
863 registration delay.
864
865 Event 6: After an interval IpubC, key N+1 becomes ready (in that all
866 caches that have a copy of the DNSKEY RRset have a copy of this key).
867 This time is the ready time of the successor key N+1 (Trdy).
868
869 Event 7: At the submission time of the successor key N+1, Tsbm(N+1),
870 the DS record corresponding to key N+1 is submitted to the parent
871 zone.
872
873
874
875
876
877 Morris, et al. Informational [Page 16]
878 RFC 7583 Key Timing October 2015
879
880
881 Event 8: The successor DS record is published in the parent zone and
882 the current DS record withdrawn. Key N is said to be retired and the
883 time at which this occurs is Tret(N), given by:
884
885 Tret(N) = Tsbm(N+1) + Dreg
886
887 Event 9: Key N must remain in the zone until any caches that contain
888 a copy of the DS RRset have a copy containing the new DS record.
889 This interval is the retire interval, given by:
890
891 Iret = DprpP + TTLds
892
893 ... where DprpP is the propagation delay in the parent zone and TTLds
894 the TTL of a DS record in the parent zone.
895
896 As the key is no longer used for anything, it is said to be dead.
897 This point is the dead time (Tdea), given by:
898
899 Tdea(N) = Tret(N) + Iret
900
901 Event 10: At some later time, key N is removed from the zone's DNSKEY
902 RRset (at the remove time Trem); the key is now said to be removed.
903
904 Trem(N) >= Tdea(N)
905
906 3.3.2. Double-DS Method
907
908 In this rollover, the new DS record is published in the parent zone.
909 When any caches that contain the DS RRset contain a copy of the new
910 record, the KSK in the zone is changed. After a further interval for
911 the old DNSKEY RRset to expire from caches, the old DS record is
912 removed from the parent.
913
914 The timeline for a Double-DS rollover is shown below. The diagram
915 follows the convention described in Section 3.2.1.
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932 Morris, et al. Informational [Page 17]
933 RFC 7583 Key Timing October 2015
934
935
936 |1| |2| |3| |4| |5|
937 | | | | |
938 Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk---- - -
939 | | | | |
940 Key N+1 | | | | |<--Dreg-- - -
941 | | | | |
942 Key N Tsbm Tpub Trdy Tact
943 Key N+1 Tsbm
944 ---- Time ---->
945
946 (continued ...)
947
948 |6| |7| |8| |9| |10|
949 | | | | |
950 Key N - ----------Lksk--------->|<-Iret->|<---->|
951 | | | | |
952 Key N+1 - --Dreg-->|<-IpubP->|<-->|<---Lksk------- - -
953 | | | | |
954 Key N Tret Tdea Trem
955 Key N+1 Tpub Trdy Tact
956
957 ---- Time ---->
958
959 Figure 4: Timeline for a Double-DS KSK Rollover
960
961 Event 1: The DS RR is submitted to the parent zone for publication.
962 This time is the submission time, Tsbm.
963
964 Event 2: After the registration delay, Dreg, the DS record is
965 published in the parent zone. This is the publication time (Tpub) of
966 key N, given by:
967
968 Tpub(N) = Tsbm(N) + Dreg
969
970 As before, in practice, Dreg will not be a fixed time. Instead, the
971 end of Dreg will be signaled by the appearance of the DS record in
972 the parent zone.
973
974 Event 3: At some later time, any cache that has a copy of the DS
975 RRset will have a copy of the DS record for key N. At this point,
976 key N, if introduced into the DNSKEY RRset, could be used to validate
977 the zone. For this reason, this time is known as the ready time,
978 Trdy, and is given by:
979
980 Trdy(N) = Tpub(N) + IpubP
981
982
983
984
985
986
987 Morris, et al. Informational [Page 18]
988 RFC 7583 Key Timing October 2015
989
990
991 IpubP is the publication interval of the DS record (in the parent
992 zone) and is given by the expression:
993
994 IpubP = DprpP + TTLds
995
996 ... where DprpP is the propagation delay for the parent zone and
997 TTLds the TTL assigned to DS records in that zone.
998
999 Event 4: At some later time, the key rollover takes place and the new
1000 key (key N) is introduced into the DNSKEY RRset and used to sign it.
1001 This time is key N's activation time (Tact) and at this point key N
1002 is said to be active:
1003
1004 Tact(N) >= Trdy(N)
1005
1006 Event 5: At some point, thought must be given to key replacement.
1007 The DS record for the successor key must be submitted to the parent
1008 zone at a time such that when the current key is withdrawn, any cache
1009 that contains the zone's DS records has data about the DS record of
1010 the successor key. The time at which this occurs is the submission
1011 time of the successor key N+1, given by:
1012
1013 Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg
1014
1015 ... where Lksk is the actual lifetime of key N (which may differ
1016 slightly from the lifetime set in the key management policy) and Dreg
1017 is the registration delay.
1018
1019 Event 6. After an interval Dreg, the successor DS record is
1020 published in the zone.
1021
1022 Event 7: The successor key (key N+1) enters the ready state, i.e.,
1023 its DS record is now in caches that contain the parent DS RRset.
1024
1025 Event 8: When key N has been active for its lifetime (Lksk), it is
1026 replaced in the DNSKEY RRset by key N+1; the RRset is then signed
1027 with the new key. At this point, as both the old and new DS records
1028 have been in the parent zone long enough to ensure that they are in
1029 caches that contain the DS RRset, the zone can be authenticated
1030 throughout the rollover. A validating resolver can authenticate
1031 either the old or new KSK.
1032
1033 This time is the retire time (Tret) of key N, given by:
1034
1035 Tret(N) = Tact(N) + Lksk
1036
1037 This is also the activation time of the successor key N+1.
1038
1039
1040
1041
1042 Morris, et al. Informational [Page 19]
1043 RFC 7583 Key Timing October 2015
1044
1045
1046 Event 9: At some later time, all copies of the old DNSKEY RRset have
1047 expired from caches and the old DS record is no longer needed. In
1048 analogy with other rollover methods, this is called the dead time,
1049 Tdea, and is given by:
1050
1051 Tdea(N) = Tret(N) + Iret
1052
1053 ... where Iret is the retire interval of the key, given by:
1054
1055 Iret = DprpC + TTLkey
1056
1057 As before, this term includes DprpC, the time taken to propagate the
1058 RRset change through the master-slave hierarchy of the child zone and
1059 TTLkey, the time taken for the DNSKEY RRset to expire from caches.
1060
1061 Event 10: At some later time, the DS record is removed from the
1062 parent zone. In analogy with other rollover methods, this is the
1063 removal time (Trem), given by:
1064
1065 Trem(N) >= Tdea(N)
1066
1067 3.3.3. Double-RRset Method
1068
1069 In the Double-RRset rollover, the new DNSKEY and DS records are
1070 published simultaneously in the appropriate zones. Once enough time
1071 has elapsed for the old DNSKEY and DS RRsets to expire from caches,
1072 the old DNSKEY and DS records are removed from their respective
1073 zones.
1074
1075 The timeline for this rollover is shown below. The diagram follows
1076 the convention described in Section 3.2.1.
1077
1078 |1| |2| |3| |4| |5|
1079 | | | | |
1080 Key N |<-----------Lksk---------->|<---->|
1081 | | | | |
1082 | |<------Ipub----->| |
1083 | | | | |
1084 | |<-Dreg->|<-Iret->| |
1085 | | | | |
1086 Key N+1 | | |<----Lksk-------- - -
1087 | | | | |
1088 Key N Tact Tret Tdea Trem
1089 Key N+1 Tpub Tact
1090
1091 ---- Time ---->
1092
1093 Figure 5: Timeline for a Double-RRset KSK Rollover
1094
1095
1096
1097 Morris, et al. Informational [Page 20]
1098 RFC 7583 Key Timing October 2015
1099
1100
1101 Event 1: The DS and DNSKEY records have appeared in their respective
1102 zones and the latter has been used to sign the DNSKEY RRset. The key
1103 is published and active: this is key N's activation time (Tact).
1104
1105 Event 2: As the current key (key N) approaches the end of its actual
1106 lifetime (Lksk), the successor key (key N+1) is introduced into the
1107 zone and is used to sign the DNSKEY RRset. At the same time, the
1108 successor DS record is submitted to the parent zone. This is the
1109 publication time of the successor key (Tpub):
1110
1111 Tpub(N+1) <= Tact(N) + Lksk - Ipub
1112
1113 ... where Ipub is defined below.
1114
1115 Event 3: After the registration delay (Dreg), the DS record appears
1116 in the parent zone. The DNSKEY record is already in the child zone,
1117 so with both the new key and its associated data now visible, this is
1118 the key's activation time (Tact) and the key is now said to be
1119 active.
1120
1121 Tact(N+1) = Tpub(N+1) + Dreg
1122
1123 Event 4: Before key N and its associated data can be withdrawn, all
1124 RRsets in the caches of validating resolvers must contain the new DS
1125 and/or DNSKEY. The time at which this occurs is the dead time of key
1126 N (Tdea), given by:
1127
1128 Tdea(N) = Tpub(N+1) + Ipub
1129
1130 Ipub is the time it takes to guarantee that any prior cached
1131 information about the DNSKEY and the DS RRsets have expired. For the
1132 DNSKEY, this is the publication interval of the child (IpubC). For
1133 the DS, the publication interval (IpubP) starts once the record
1134 appears in the parent zone, which is Dreg after it has been
1135 submitted. Hence:
1136
1137 Ipub = max(Dreg + IpubP, IpubC)
1138
1139 The parent zone's publication interval is given by:
1140
1141 IpubP = DprpP + TTLds
1142
1143 where DprpP is the parent zone's propagation delay and TTLds is the
1144 TTL of the DS record in that zone.
1145
1146
1147
1148
1149
1150
1151
1152 Morris, et al. Informational [Page 21]
1153 RFC 7583 Key Timing October 2015
1154
1155
1156 The child zone's publication interval is given by a similar equation:
1157
1158 IpubC = DprpC + TTLkey
1159
1160 where DprpC is the propagation delay in the child zone and TTLkey the
1161 TTL of a DNSKEY record.
1162
1163 In analogy with other rollovers, we can also define a retire interval
1164 -- the interval between a key becoming active and the time at which
1165 its predecessor is considered dead. In this case, Iret is given by:
1166
1167 Iret = Ipub - Dreg
1168
1169 In other words, the retire interval of the predecessor key is the
1170 greater of the publication interval of the parent, or the publication
1171 interval of the child minus the registration delay.
1172
1173 Event 5: At some later time, the key N's DS and DNSKEY records are
1174 removed from their respective zones. In analogy with other rollover
1175 methods, this is the removal time (Trem), given by:
1176
1177 Trem(N) >= Tdea(N)
1178
1179 3.3.4. Interaction with Configured Trust Anchors
1180
1181 Although the preceding sections have been concerned with rolling
1182 KSKs, where the trust anchor is a DS record in the parent zone, zone
1183 managers may want to take account of the possibility that some
1184 validating resolvers may have configured trust anchors directly.
1185
1186 Rolling a configured trust anchor is dealt with in [RFC5011]. It
1187 requires introducing the KSK to be used as the trust anchor into the
1188 zone for a period of time before use and retaining it (with the
1189 "revoke" bit set) for some time after use.
1190
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
1191 3.3.4.1. Addition of KSK
1192
1193 When the new key is introduced, the expression for the publication
1194 interval of the DNSKEY (IpubC) in the Double-KSK and Double-RRset
1195 methods is modified to:
1196
1197 IpubC >= DprpC + max(Itrp, TTLkey)
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207 Morris, et al. Informational [Page 22]
1208 RFC 7583 Key Timing October 2015
1209
1210
1211 ... where the right-hand side of the expression now includes the
1212 "trust point" interval. This term is the interval required to
1213 guarantee that a resolver configured for the automatic update of keys
1214 according to [RFC5011] will accept the new key as a new trust point.
1215 That interval is given by:
1216
1217 Itrp >= queryInterval + AddHoldDownTime + queryInterval
1218
1219 ... where queryInterval is as defined in Section 2.3 of [RFC5011] and
1220 AddHoldDownTime is the Add Hold-Down Time defined in Section 2.4.1 of
1221 the same document.
1222
1223 The first term of the expression (queryInterval) represents the time
1224 after which all validating resolvers can be guaranteed to have
1225 obtained a copy of the DNSKEY RRset containing the new key. Once
1226 retrieved, a validating resolver needs to wait for AddHoldDownTime.
1227 Providing it does not see a validly signed DNSKEY RRset without the
1228 new key in that period, it will treat it as a trust anchor the next
1229 time it retrieves the RRset, a process that can take up to another
1230 queryInterval (the third term).
1231
1232 However, the expression for queryInterval given in [RFC5011] contains
1233 the DNSKEY's RRSIG expiration interval, a parameter that only the
1234 validating resolver can really calculate. In practice, a modified
1235 query interval that depends only on TTLkey can be used:
1236
1237 modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
1238
1239 (This is obtained by taking the expression for queryInterval in
1240 [RFC5011] and assuming a worst case for RRsigExpirationInterval. It
1241 is greater than or equal to queryInterval for all values of the
1242 expiration time.) The expression above then becomes (after
1243 collecting terms):
1244
1245 Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval
1246
1247 In the Double-DS method, instead of swapping the KSK RRs in a single
1248 step, there must now be a period of overlap. In other words, the new
1249 KSK must be introduced into the zone at least:
1250
1251 DprpC + max(Itrp, TTLkey)
1252
1253 ... before the switch is made.
1254
1255
1256
1257
1258
1259
1260
1261
1262 Morris, et al. Informational [Page 23]
1263 RFC 7583 Key Timing October 2015
1264
1265
1266 3.3.4.2. Removal of KSK
1267
1268 The timeline for the removal of the key in all methods is modified by
1269 introducing a new state, "revoked". When the key reaches its dead
1270 time, instead of being declared "dead", it is revoked; the "revoke"
1271 bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed
1272 with the current and revoked keys. The key is maintained in this
1273 state for the revoke interval, Irev, given by:
1274
1275 Irev >= DprpC + modifiedQueryInterval
1276
1277 As before, DprpC is the time taken for the revoked DNSKEY to
1278 propagate to all slave zones, and modifiedQueryInterval is the time
1279 after which it can be guaranteed that all validating resolvers that
1280 adhere to RFC 5011 have retrieved a copy of the DNSKEY RRset
1281 containing the revoked key.
1282
1283 After this time, the key is dead and can be removed from the zone.
1284
1285 3.3.5. Introduction of First Keys
1286
1287 There are no timing considerations associated with the introduction
1288 of the first keys into a zone other that they must be introduced and
1289 the zone validly signed before a chain of trust to the zone is
1290 created.
1291
1292 In the case of a secure parent, it means ensuring that the DS record
1293 is not published in the parent zone until there is no possibility
1294 that a validating resolver can obtain the record yet is not able to
1295 obtain the corresponding DNSKEY. In the case of an insecure parent,
1296 i.e., the initial creation of a chain of trust or "security apex", it
1297 is not possible to guarantee this. It is up to the operator of the
1298 validating resolver to wait for the new KSK to appear at all servers
1299 for the zone before configuring the trust anchor.
1300
1301 4. Standby Keys
1302
1303 Although keys will usually be rolled according to some regular
1304 schedule, there may be occasions when an emergency rollover is
1305 required, e.g., if the active key is suspected of being compromised.
1306 The aim of the emergency rollover is to allow the zone to be
1307 re-signed with a new key as soon as possible. As a key must be in
1308 the ready state to sign the zone, having at least one additional key
1309 (a standby key) in this state at all times will minimize delay.
1310
1311 In the case of a ZSK, a standby key only really makes sense with the
1312 Pre-Publication method. A permanent standby DNSKEY RR should be
1313 included in the zone or successor keys could be introduced as soon as
1314
1315
1316
1317 Morris, et al. Informational [Page 24]
1318 RFC 7583 Key Timing October 2015
1319
1320
1321 possible after a key becomes active. Either way results in one or
1322 more additional ZSKs in the DNSKEY RRset that can immediately be used
1323 to sign the zone if the current key is compromised.
1324
1325 (Although, in theory, the mechanism could be used with both the
1326 Double-Signature and Double-RRSIG methods, it would require
1327 pre-publication of the signatures. Essentially, the standby key
1328 would be permanently active, as it would have to be periodically used
1329 to renew signatures. Zones would also permanently require two sets
1330 of signatures.)
1331
1332 It is also possible to have a standby KSK. The Double-KSK method
1333 requires that the standby KSK be included in the DNSKEY RRset;
1334 rolling the key then requires just the introduction of the DS record
1335 in the parent. Note that the standby KSK should also be used to sign
1336 the DNSKEY RRset. As the RRset and its signatures travel together,
1337 merely adding the KSK without using it to sign the DNSKEY RRset does
1338 not provide the desired time saving: for a KSK to be used in a
1339 rollover, the DNSKEY RRset must be signed with it, and this would
1340 introduce a delay while the old RRset (not signed with the new key)
1341 expires from caches.
1342
1343 The idea of a standby KSK in the Double-RRset rollover method
1344 effectively means having two active keys (as the standby KSK and
1345 associated DS record would both be published at the same time in
1346 their respective zones).
1347
1348 Finally, in the Double-DS method of rolling a KSK, it is not a
1349 standby key that is present, it is a standby DS record in the parent
1350 zone.
1351
1352 Whatever algorithm is used, the standby item of data can be included
1353 in the zone on a permanent basis, or be a successor introduced as
1354 early as possible.
1355
1356 5. Algorithm Considerations
1357
1358 The preceding sections have implicitly assumed that all keys and
1359 signatures are created using a single algorithm. However,
1360 Section 2.2 of [RFC4035] requires that there be an RRSIG for each
1361 RRset using at least one DNSKEY of each algorithm in the zone apex
1362 DNSKEY RRset.
1363
1364 Except in the case of an algorithm rollover -- where the algorithms
1365 used to create the signatures are being changed -- there is no
1366 relationship between the keys of different algorithms. This means
1367 that they can be rolled independently of one another. In other
1368
1369
1370
1371
1372 Morris, et al. Informational [Page 25]
1373 RFC 7583 Key Timing October 2015
1374
1375
1376 words, the key-rollover logic described above should be run
1377 separately for each algorithm; the union of the results is included
1378 in the zone, which is signed using the active key for each algorithm.
1379
1380 6. Summary
1381
1382 For ZSKs, the Pre-Publication method is generally considered to be
1383 the preferred way of rolling keys. As shown in this document, the
1384 time taken to roll is wholly dependent on parameters under the
1385 control of the zone manager.
1386
1387 In contrast, the Double-RRset method is the most efficient for KSK
1388 rollover due to the ability to have new DS records and DNSKEY RRsets
1389 propagate in parallel. The time taken to roll KSKs may depend on
1390 factors related to the parent zone if the parent is signed. For
1391 zones that intend to comply with the recommendations of [RFC5011], in
1392 many cases, the rollover time will be determined by the times defined
1393 by RFC 5011. It should be emphasized that this delay is a policy
1394 choice and not a function of timing values and that it also requires
1395 changes to the rollover process due to the need to manage revocation
1396 of trust anchors.
1397
1398 Finally, the treatment of emergency key rollover is significantly
1399 simplified by the introduction of standby keys as standard practice
1400 during all types of rollovers.
1401
1402 7. Security Considerations
1403
1404 This document does not introduce any new security issues beyond those
1405 already discussed in [RFC4033], [RFC4034], [RFC4035], and [RFC5011].
1406
1407 8. Normative References
1408
1409 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1410 Rose, "DNS Security Introduction and Requirements",
1411 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1412 <http://www.rfc-editor.org/info/rfc4033>.
1413
1414 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1415 Rose, "Resource Records for the DNS Security Extensions",
1416 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1417 <http://www.rfc-editor.org/info/rfc4034>.
1418
1419 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1420 Rose, "Protocol Modifications for the DNS Security
1421 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1422 <http://www.rfc-editor.org/info/rfc4035>.
1423
1424
1425
1426
1427 Morris, et al. Informational [Page 26]
1428 RFC 7583 Key Timing October 2015
1429
1430
1431 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
1432 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
1433 September 2007, <http://www.rfc-editor.org/info/rfc5011>.
1434
1435 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
1436 Operational Practices, Version 2", RFC 6781,
1437 DOI 10.17487/RFC6781, December 2012,
1438 <http://www.rfc-editor.org/info/rfc6781>.
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482 Morris, et al. Informational [Page 27]
1483 RFC 7583 Key Timing October 2015
1484
1485
1486 Appendix A. List of Symbols
1487
1488 The document defines a number of symbols, all of which are listed
1489 here. All are of the form:
1490
1491 <TYPE><id><ZONE>
1492
1493 where:
1494
1495 <TYPE> is an uppercase character indicating what type the symbol is.
1496 Defined types are:
1497
1498 D delay: interval that is a feature of the process
1499
1500 I interval between two events
1501
1502 L lifetime: interval set by the zone manager
1503
1504 T a point in time
1505
1506 TTL TTL of a record
1507
1508 I, T, and TTL are self-explanatory. Like I, both D and L are time
1509 periods, but whereas I values are intervals between two events, a "D"
1510 interval (delay) is a feature of the process, probably outside
1511 control of the zone manager, and an "L" interval (lifetime) is chosen
1512 by the zone manager and is a feature of policy.
1513
1514 <id> is lowercase and defines what object or event the variable is
1515 related to, e.g.,
1516
1517 act activation
1518
1519 pub publication
1520
1521 ret retire
1522
1523 <ZONE> is an optional uppercase letter that distinguishes between the
1524 same variable applied to different zones and is one of:
1525
1526 C child
1527
1528 P parent
1529
1530 Within the rollover descriptions, times may have a number in
1531 parentheses affixed to their end indicating the instance of the key
1532 to which they apply, e.g., Tact(N) is the activation time of key N,
1533 Tpub(N+1) the publication time of key N+1 etc.
1534
1535
1536
1537 Morris, et al. Informational [Page 28]
1538 RFC 7583 Key Timing October 2015
1539
1540
1541 The list of variables used in the text given below.
1542
1543 Dprp Propagation delay. The amount of time for a change made at
1544 a master nameserver to propagate to all the slave
1545 nameservers.
1546
1547 DprpC Propagation delay in the child zone.
1548
1549 DprpP Propagation delay in the parent zone.
1550
1551 Dreg Registration delay: the time taken for a DS record
1552 submitted to a parent zone to appear in it. As a parent
1553 zone is often managed by a different organization than that
1554 managing the child zone, the delays associated with passing
1555 data between organizations is captured by this term.
1556
1557 Dsgn Signing delay. After the introduction of a new ZSK, the
1558 amount of time taken for all the RRs in the zone to be
1559 signed with it.
1560
1561 Ipub Publication interval. The amount of time that must elapse
1562 after the publication of a DNSKEY and/or its associated
1563 data before it can be assumed that any resolvers that have
1564 the relevant RRset cached have a copy of the new
1565 information.
1566
1567 IpubC Publication interval in the child zone.
1568
1569 IpubP Publication interval in the parent zone.
1570
1571 Iret Retire interval. The amount of time that must elapse after
1572 a DNSKEY or associated data enters the retire state for any
1573 dependent information (e.g., RRSIG for a ZSK) to be purged
1574 from validating resolver caches.
1575
1576 Irev Revoke interval. The amount of time that a KSK must remain
1577 published with the "revoke" bit set to satisfy
1578 considerations of [RFC5011].
1579
1580 Itrp Trust-point interval. The amount of time that a trust
1581 anchor must be published for in order to guarantee that a
1582 resolver configured for an automatic update of keys will
1583 see the new key at least twice.
1584
1585
1586
1587
1588
1589
1590
1591
1592 Morris, et al. Informational [Page 29]
1593 RFC 7583 Key Timing October 2015
1594
1595
1596 Lksk Lifetime of a KSK. This is the actual amount of time for
1597 which this particular KSK is regarded as the active KSK.
1598 Depending on when the key is rolled over, the actual
1599 lifetime may be longer or shorter than the intended key
1600 lifetime indicated by management policy.
1601
1602 Lzsk Lifetime of a ZSK. This is the actual amount of time for
1603 which the ZSK is used to sign the zone. Depending on when
1604 the key is rolled over, the actual lifetime may be longer
1605 or shorter than the intended key lifetime indicated by
1606 management policy.
1607
1608 Tact Activation time. The time at which the key is regarded as
1609 the principal key for the zone.
1610
1611 Tdea Dead time. The time at which any information held in
1612 validating resolver caches is guaranteed to contain
1613 information related to the successor key. At this point,
1614 the current key and its associated information are not
1615 longed required for validation purposes.
1616
1617 Tpub Publication time. The time that the key or associated data
1618 appears in the zone for the first time.
1619
1620 Trem Removal time. The time at which the key and its associated
1621 information starts being removed from their respective
1622 zones.
1623
1624 Tret Retire time. The time at which successor information
1625 starts being used.
1626
1627 Trdy Ready time. The time at which it can be guaranteed that
1628 validating resolvers that have information about the key
1629 and/or associated data cached have a copy of the new
1630 information.
1631
1632 Tsbm Submission time. The time at which the DS record of a KSK
1633 is submitted to the parent zone.
1634
1635 TTLds Time to live of a DS record.
1636
1637 TTLkey Time to live of a DNSKEY record. (By implication, this is
1638 also the time to live of the signatures on the DNSKEY
1639 RRset.)
1640
1641 TTLsig The maximum time to live of all the RRSIG records in the
1642 zone that were created with the ZSK.
1643
1644
1645
1646
1647 Morris, et al. Informational [Page 30]
1648 RFC 7583 Key Timing October 2015
1649
1650
1651 Acknowledgements
1652
1653 The authors gratefully acknowledge help and contributions from Roy
1654 Arends, Tim Wicinski, and Wouter Wijngaards.
1655
1656 Authors' Addresses
1657
1658 Stephen Morris
1659 Internet Systems Consortium
1660 950 Charter Street
1661 Redwood City, CA 94063
1662 United States
1663
1664 Email: stephen@isc.org
1665 URI: http://www.isc.org
1666
1667
1668 Johan Ihren
1669 Netnod
1670 Franzengatan 5
1671 Stockholm SE-112 51
1672 Sweden
1673
1674 Email: johani@netnod.se
1675 URI: http://www.netnod.se
1676
1677
1678 John Dickinson
1679 Sinodun Internet Technologies Ltd
1680 Magdalen Centre
1681 Oxford Science Park
1682 Robert Robertson Avenue
1683 Oxford, Oxfordshire OX4 4GA
1684 United Kingdom
1685
1686 Email: jad@sinodun.com
1687 URI: http://www.sinodun.com
1688
1689
1690 W. (Matthijs) Mekking
1691 Dyn, Inc.
1692 150 Dow St
1693 Manchester NH 03101
1694 United States
1695
1696 Email: mmekking@dyn.com
1697 URI: https://www.dyn.com
1698
1699
1700
1701
1702 Morris, et al. Informational [Page 31]
1703
After a careful timing analysis of the steps defined in RFC5011 and the timing described in RFC7583, issues were found that could lead to denial of service attacks. draft-rfc5011-security-considerations discusses the issues found and the suggested fixes to the timing considerations and adding additional terms to the RFC7583 Itrp equation. Specifically, this never-published draft states:
Note: The equation for Itrp in RFC7583 is insecure as it does not include the sigExpirationTime listed above [which is defined as "The amount of time between the DNSKEY RRSIG's Signature Inception field and the Signature Expiration field."]. The Itrp equation in RFC7583 also does not include the 2*TTL safety margin, though that is an operational consideration.