diff --git a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt new file mode 100644 index 0000000000..6028ee89d6 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt @@ -0,0 +1,1960 @@ + + + +Internet Engineering Task Force S. Morris +Internet-Draft ISC +Intended status: Informational J. Ihren +Expires: January 2, 2011 Netnod + J. Dickinson + Sinodun + July 1, 2010 + + + DNSSEC Key Timing Considerations + draft-ietf-dnsop-dnssec-key-timing-00.txt + +Abstract + + This document describes the issues surrounding the timing of events + in the rolling of a key in a DNSSEC-secured zone. It presents + timelines for the key rollover and explicitly identifies the + relationships between the various parameters affecting the process. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on January 2, 2011. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + + + +Morris, et al. Expires January 2, 2011 [Page 1] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 + 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 + 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 + 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 + 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 13 + 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 14 + 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17 + 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 17 + 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 20 + 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 22 + 3.3.4. Interaction with Configured Trust Anchors . . . . . . 25 + 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 25 + 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 25 + 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 26 + 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28 + 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 + 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 + Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 + + + + + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 2] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + +1. Introduction + +1.1. Key Rolling Considerations + + When a zone is secured with DNSSEC, the zone manager must be prepared + to replace ("roll") the keys used in the signing process. The + rolling of keys may be caused by compromise of one or more of the + existing keys, or it may be due to a management policy that demands + periodic key replacement for security or operational reasons. In + order to implement a key rollover, the keys need to be introduced + into and removed from the zone at the appropriate times. + Considerations that must be taken into account are: + + o DNSKEY records and associated information (such as RRSIG records + created with the key or the associated DS records) are not only + held at the authoritative nameserver, they are also cached at + client resolvers. The data on these systems can be interlinked, + e.g. a validating resolver may try to validate a signature + retrieved from a cache with a key obtained separately. + + o A query for the key RRset returns all DNSKEY records in the zone. + As there is limited space in the UDP packet (even with EDNS0 + support), dead key records must be periodically removed. (For the + same reason, the number of stand-by keys in the zone should be + restricted to the minimum required to support the key management + policy.) + + o Zone "boot-strapping" events, where a zone is signed for the first + time, can be common in configurations where a large number of + zones are being served. Procedures should be able to cope with + the introduction of keys into the zone for the first time as well + as "steady-state", where the records are being replaced as part of + normal zone maintenance. + + o To allow for an emergency re-signing of the zone as soon as + possible after a key compromise has been detected, stand-by keys + (additional keys over and above those used to sign the zone) need + to be present. + + Management policy, e.g. how long a key is used for, also needs to be + considered. However, the point of key management logic is not to + ensure that a "rollover" is completed at a certain time but rather to + ensure that no changes are made to the state of keys published in the + zone until it is "safe" to do so ("safe" in this context meaning that + at no time during the rollover process does any part of the zone ever + go bogus). In other words, although key management logic enforces + policy, it may not enforce it strictly. + + + + +Morris, et al. Expires January 2, 2011 [Page 3] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + +1.2. Types of Keys + + Although DNSSEC validation treats all keys equally, [RFC4033] + recognises the broad classification of zone-signing keys (ZSK) and + key-signing keys (KSK). A ZSK is used to authenticate information + within the zone; a KSK is used to authenticate the key set in the + zone. The main implication for this distinction concerns the + consistency of information during a rollover. + + During operation, a validating resolver must use separate pieces of + information to perform an authentication. At the time of + authentication, each piece of information may be in the validating + resolver's cache or may need to be retrieved from the authoritative + server. The rollover process needs to happen in such a way that at + all times through the rollover the information is consistent. With a + ZSK, the information is the RRSIG (plus associated RRset) and the + DNSKEY. These are both obtained from the same zone. In the case of + the KSK, the information is the DNSKEY and DS RRset with the latter + being obtained from a different zone. + + There are similarities in the rolling of ZSKs and KSKs: replace the + RRSIG (plus RR) by the DNSKEY and replace the DNSKEY by the DS, and + the ZSK rolling algorithms are virtually the same as the KSK + algorithms. However, there are a number of differences, and for this + reason the two types of rollovers are described separately in this + document. + +1.3. Terminology + + The terminology used in this document is as defined in [RFC4033] and + [RFC5011]. + + A large number of symbols are used to identify times, intervals, etc. + All are listed in Appendix A. + + +2. Rollover Methods + +2.1. ZSK Rollovers + + A ZSK can be rolled in one of three ways: + + o Pre-Publication. Described in [RFC4641], the new key is + introduced into the DNSKEY RRset, leaving the existing keys and + signatures in place. This state of affairs remains in place for + long enough to ensure that any DNSKEY RRsets cached in client + validating resolvers contain both keys. At that point signatures + created with the old key can be replaced by those created with the + + + +Morris, et al. Expires January 2, 2011 [Page 4] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + new key, and the old signatures removed. During the re-signing + process (which may or may not be atomic depending on how the zone + is managed), it doesn't matter which key an RRSIG record retrieved + by a client was created with; clients with a cached copy of the + DNSKEY RRset will have a copy containing both the old and new + keys. + + Once the zone contains only signatures created with the new key, + there is an interval during which RRSIG records created with the + old key expire from client caches. After this, there will be no + signatures anywhere that were created using the old key, and it + can can be removed from the DNSKEY RRset. + + o Double-Signature. Also mentioned in [RFC4641], this involves + introducing the new key into the zone and using it to create + additional RRSIG records; the old key and existing RRSIG records + are retained. During the period in which the zone is being signed + (again, the signing process may not be atomic), client resolvers + are always able to validate RRSIGs: any combination of old and new + DNSKEY RRset and RRSIG allows at least one signature to be + validated. + + Once the signing process is complete and enough time has elapsed + to allow all old information to expire from caches, the old key + and signatures can be removed from the zone. As before, during + this period any combination of DNSKEY RRset and RRSIG will allow + validation of at least one signature. + + o Double-RRSIG. Strictly speaking, the use of the term "Double- + Signature" above is a misnomer as the method is not only double + signature, it is also double key as well. A true Double-Signature + method (here called the Double-RRSIG method) involves introducing + new signatures in the zone (while still retaining the old ones) + but not the new key. + + Once the signing process is complete and enough time has elapsed + to ensure that all caches that may contain an RR and associated + RRSIG to have a copy of both signatures, the ZSK is changed. + After a further interval during which the old DNSKEY RRset expires + from caches, the old signatures are removed from the zone. + + Of three methods, Double-Signature is the simplest conceptually - + introduce the new key and new signatures, then approximately one TTL + later remove the old key and signatures. The drawback of this method + is a noticeable increase in the size of the DNSSEC data, affecting + both the overall size of the zone and the size of the responses. + + Pre-Publication is more complex - introduce the new key, + + + +Morris, et al. Expires January 2, 2011 [Page 5] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + approximately one TTL later sign the records, and approximately one + TTL after that remove the old key. However, the amount of DNSSEC + data is kept to a minimum which reduces the impact on performance. + + The Double-RRSIG combines the increase in data volume of the Double- + Signature method with the complexity of Pre-Publication. It has few + (if any) advantages and a description is only included here for + completeness. + +2.2. KSK Rollovers + + In the ZSK case the issue for the validating resolver is to ensure + that it has access to the ZSK that corresponds to a particular + signature. In the KSK case this can never be a problem as the KSK is + only used for one signature (that over the DNSKEY RRset) and both the + key the signature travel together. Instead, the issue is to ensure + that the KSK is trusted. + + Trust in the KSK is either due to the existence of an explicitly + configured trust anchor in the validating resolver or DS record in + the parent zone (which is itself trusted). If the former, [RFC5011] + timings will be needed to roll the keys. If the latter, the rollover + algorithm will need to involve the parent zone in the addition and + removal of DS records, so timings are not wholly under the control of + the zone manager. (The zone manager may elect to include [RFC5011] + timings in the key rolling process so as to cope with the possibility + that the key has also been explicitly configured as a trust anchor.) + + It is important to note that this does not preclude the development + of key rollover logic; in accordance with the goal of the rollover + logic being able to determine when a state change is "safe", the only + effect of being dependent on the parent is that there may be a period + of waiting for the parent to respond in addition to any delay the key + rollover logic requires. Although this introduces additional delays, + even with a parent that is less than ideally responsive the only + effect will be a slowdown in the rollover state transitions. This + may cause a policy violation, but will not cause any operational + problems. + + Like the ZSK case, there are three methods for rolling a KSK: + + o Double-Signature: Also known as Double-DNSKEY, the new KSK is + added to the DNSKEY RRset which is then signed with both the old + and new key. After waiting for the old RRset to expire from + caches, the DS record in the parent zone is changed. After + waiting a further interval for this change to be reflected in + caches, the old key is removed from the RRset. (The name "Double- + Signature" is used because, like the ZSK method of the same name, + + + +Morris, et al. Expires January 2, 2011 [Page 6] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + the new key is introduced and immediately used for signing.) + + o Double-DS: the new DS record is published. After waiting for this + change to propagate into the caches of all validating resolvers, + the KSK is changed. After a further interval during which the old + DNSKEY RRset expires from caches, the old DS record is removed. + + o Double-RRset: the new KSK is added to the DNSKEY RRset which is + then signed with both the old and new key, and the new DS record + added to the parent zone. After waiting a suitable interval for + the old DS and DNSKEY RRsets to expire from validating resolver + caches, the old DNSKEY and DS record are removed. + + In essence, "Double-Signature" means that the new KSK is introduced + first and used to sign the DNSKEY RRset. The DS record is changed, + and finally the old KSK removed. With "Double-DS" it is the other + way around. Finally, Double-RRset does both updates more or less in + parallel. + + The strategies have different advantages and disadvantages: + + o Double-Signature minimizes the number of interactions with the + parent zone. However, for the period of the rollover the DNSKEY + RRset is signed with two KSKs, so increasing the size of the + response to a query for this data. + + o Double-DS keeps the size of the DNSKEY RRset to a minimum, but + does require the additional administrative overhead of two + interactions with the parent to roll a KSK. (Although this can be + mitigated if the parent has the ability for a child zone to + schedule the withdrawal of the old key at the same time as the + introduction of the new one.) + + o Finally, Double-RRset allows the rollover to be done in roughly + half the time of the other two methods; it also supports policies + that require a period of running with old and new KSKs + simultaneously. However, it does have the disadvantages of both + the other two methods - it requires two signatures during the + period of the rollover and two interactions with the parent. + +2.3. Summary + + The methods can be summarised as follows: + + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 7] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + +------------------+------------------+-----------------------------+ + | ZSK Method | KSK Method | Description | + +------------------+------------------+-----------------------------+ + | Pre-Publication | (not applicable) | Publish the DNSKEY before | + | | | the RRSIG. | + | Double-Signature | Double-Signature | Publish the DNSKEY and | + | | | RRSIG at same time. (For a | + | | | KSK, this happens before | + | | | the DS is published.) | + | Double-RRSIG | (not applicable) | Publish RRSIG before the | + | | | DNSKEY. | + | (not applicable) | Double-DS | Publish DS before the | + | | | DNSKEY. | + | (not applicable) | Double-RRset | Publish DNSKEY and DS in | + | | | parallel. | + +------------------+------------------+-----------------------------+ + + Table 1 + + +3. Key Rollover Timelines + +3.1. Key States + + During the rolling process, a key moves through different states. + These states are: + + Generated The key has been created, but has not yet been used for + anything. + + Published The DNSKEY record - or information associated with it - + is published in the zone, but predecessors of the key (or + associated information) may be held in resolver caches. + + The idea of "associated information" is used in rollover + methods where RRSIG or DS records are published first and + the DNSKEY is changed in an atomic operation. It allows + the rollover still to be thought of as moving through a + set of states. In the rest of this section, the term + "key" should be taken to mean "key or associated + information". + + Ready The key has been published for long enough to guarantee + that all caches that might contain a copy of the key + RRset have a copy that includes this key. + + + + + + +Morris, et al. Expires January 2, 2011 [Page 8] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Active The key is in the zone and has started to be used to sign + RRsets or authenticate the DNSKEY RRset. Note that when + this state is entered, it might not be possible for every + validating resolver to use the key for validation: the + zone signing may not have finished, or the data might not + have reached the resolver because of propagation delays + and/or caching issues. If this is the case, the resolver + will have to rely on the key's predecessor instead. + + Retired The key is in the zone but a successor key has become + active. As there may still be information in caches that + that require use of the key, it is being retained until + this information expires. + + Dead The key is published in the zone but there is no + information anywhere that requires its presence. + + Removed The key has been removed from the zone. + + There is one additional state, used where [RFC5011] considerations + are in effect (see Section 3.3.4): + + Revoked The key is published for a period with the "revoke" bit + set as a way of notifying validating resolvers that have + configured it as a trust anchor that it is about to be + removed from the zone. + +3.2. Zone-Signing Key Timelines + +3.2.1. Pre-Publication Method + + The following diagram shows the time line of a particular ZSK and its + replacement by its successor using the Pre-Publication method. Time + increases along the horizontal scale from left to right and the + vertical lines indicate events in the life of the key. The events + are numbered; significant times and time intervals are marked. + + + + + + + + + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 9] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + |1| |2| |3| |4| |5| |6| |7| |8| |9| + | | | | | | | | | + Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| + | | | | | | | | | + Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - + | | | | | | | | | + Tgen Tpub Trdy Tact TpubS Tret Tdea Trem + + ---- Time ----> + + + Figure 1: Timeline for a Pre-Publication ZSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to publication in the zone (Event 2), some implementations may find + it convenient to create a pool of keys in one operation and draw from + that pool as required. For this reason, it is shown as a separate + event. Keys that are available for use but not published are said to + be generated. + + Event 2: key N's DNSKEY record is put into the zone, i.e. it is added + to the DNSKEY RRset which is then re-signed with the current key- + signing key. The time at which this occurs is the key's publication + time (Tpub), and the key is now said to be published. Note that the + key is not yet used to sign records. + + Event 3: before it can be used, the key must be published for long + enough to guarantee that any resolver that has a copy of the DNSKEY + RRset from the zone in its cache will have a copy of the RRset that + includes this key: in other words, that any prior cached information + about the DNSKEY RRset has expired. + + This interval is the publication interval (Ipub) and, for the second + or subsequent keys in the zone, is given by: + + Ipub = Dprp + TTLkey + + Here, Dprp is the propagation delay - the time taken for any change + introduced at the master to replicate to all slave servers - which + depends on the depth of the master-slave hierarchy. TTLkey is the + time-to-live (TTL) for the DNSKEY records in the zone. The sum is + therefore the time taken for existing DNSKEY records to expire from + the caches of downstream validating resolvers, regardless of the + nameserver from which they were retrieved. + + In the case of the first key in the zone, Ipub is slightly different + because it is not information about a DNSKEY RRset that may be + + + +Morris, et al. Expires January 2, 2011 [Page 10] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + cached, it is information about its absence. In this case: + + Ipub = Dprp + Ingc + + where Ingc is the negative cache interval from the zone's SOA record, + calculated according to [RFC2308] as the minimum of the TTL of the + SOA record itself (TTLsoa), and the "minimum" field in the record's + parameters (SOAmin), i.e. + + Ingc = min(TTLsoa, SOAmin) + + After a delay of Ipub, the key is said to be ready and could be used + to sign records. The time at which this event occurs is the key's + ready time (Trdy), which is given by: + + Trdy = Tpub + Ipub + + Event 4: at some later time, the key starts being used to sign + RRsets. This point is the active time (Tact) and after this, the key + is said to be active. + + Event 5: while this key is active, thought must be given to its + successor (key N+1). As with the introduction of the currently + active key into the zone, the successor key will need to be published + at least Ipub before it is used. Denoting the publication time of + the successor key by TpubS, then: + + TpubS <= Tact + Lzsk - Ipub + + Here, Lzsk is the length of time for which a ZSK will be used (the + ZSK lifetime). It should be noted that unlike the publication + interval, Lzsk is not determined by timing logic, but by key + management policy. Lzsk will be set by the operator according to + their assessment of the risks posed by continuing to use a key and + the risks associated with key rollover. However, operational + considerations may mean a key is active for slightly more or less + than Lzsk. + + Event 6: while the key N is still active, its successor becomes + ready. From this time onwards, it could be used to sign the zone. + + Event 7: at some point the decision is made to start signing the zone + using the successor key. This will be when the current key has been + in use for an interval equal to the ZSK lifetime, hence: + + Tret = Tact + Lzsk + + This point in time is the retire time (Tret) of key N; after this the + + + +Morris, et al. Expires January 2, 2011 [Page 11] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + key is said to be retired. (This time is also the point at which the + successor key becomes active.) + + Event 8: the retired key needs to be retained in the zone whilst any + RRSIG records created using this key are still published in the zone + or held in resolver caches. (It is possible that a resolver could + have an unexpired RRSIG record and an expired DNSKEY RRset in the + cache when it is asked to provide both to a client. In this case the + DNSKEY RRset would need to be looked up again.) This means that once + the key is no longer used to sign records, it should be retained in + the zone for at least the retire interval (Iret) given by: + + Iret = Dsgn + Dprp + TTLsig + + Dsgn is the delay needed to ensure that all existing RRsets have been + re-signed with the new key. Dprp is (as described above) the + propagation delay, required to guarantee that the updated zone + information has reached all slave servers, and TTLsig is the TTL of + the RRSIG records. + + (It should be noted that an upper limit on the retire interval is + given by: + + Iret = Lsig + Dskw + + where Lsig is the lifetime of a signature (i.e. the interval between + the time the signature was created and the signature end time), and + Dskw is the clock skew - the maximum difference in time between the + server and a validating resolver. The reasoning here is that + whatever happens, a key only has to be available while any signatures + created with it are valid. Wherever a signature record is held - + published in the zone and/or held in a resolver cache - it won't be + valid for longer than Lsig after it was created. The Dskw term is + present to account for the fact that the signature end time is an + absolute time rather than interval, and systems may not agree exactly + about the time.) + + The time at which all RRSIG records created with this key have + expired from resolver caches is the dead time (Tdea), given by: + + Tdea = Tret + Iret + + ...at which point the key is said to be dead. + + Event 9: at any time after the key becomes dead, it can be removed + from the zone and the DNSKEY RRset re-signed with the current key- + signing key. This time is the removal time (Trem), given by: + + + + +Morris, et al. Expires January 2, 2011 [Page 12] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Trem >= Tdea + + ...at which time the key is said to be removed. + +3.2.2. Double-Signature Method + + In the Double-Signature method, both the new key and signatures + created using it are introduced at the same time. After a period + during which this information propagates to validating resolver + caches, the old key and signature are removed. The time line for the + method is shown below: + + + + |1| |2| |3| |4| |5| |6| + | | | | | | + Key N | |<-------Lzsk------>|<-----Iret----->| | + | | | | | | + Key N+1 | | | |<----------Lzsk------- - - + | | | | | | + Tgen Tact Tret Tdea Trem + + ---- Time ----> + + + Figure 2: Timeline for a Double-Signature ZSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to publication in the zone (Event 2), some implementations may find + it convenient to create a pool of keys in one operation and draw from + that pool as required. For this reason, it is shown as a separate + event. Keys that are available for use but not published are said to + be generated. + + Event 2: key N is added to the DNSKEY RRset and is immediately used + to sign the zone; existing signatures in the zone are not removed. + This is the active time (Tact) and the key is said to be active. + + Event 3: at some time later, the predecessor key (key N-1) and its + signatures can be withdrawn from the zone. (The timing of key + removal is discussed further in the description of event 5.) + + Event 4: the successor key (key N+1) is introduced into the zone and + starts being used to sign RRsets. The successor is key is now active + and the current key (key N) is said to be retired. This time is the + retire time of the key (Tret); it is also the active time of the + successor key (TactS). + + + +Morris, et al. Expires January 2, 2011 [Page 13] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Tret = Tact + Lzsk + + Event 5: before key N can be withdrawn from the zone, all RRsets that + need to be signed must have been signed by the successor key (as a + result, all these RRsets are now signed twice, once by key N and once + by its successor) and the information must have reached all + validating resolvers that may have RRsets from this zone cached. + + This takes Iret, the retire interval, given by the expression: + + Iret = Dsgn + Dprp + max(TTLkey, TTLsig) + + As before, Dsgn is the time taken to sign the zone with the new key + and Dprp is the propagation delay. The final term is the period to + wait for old key and signature data to expire from caches. After the + end of this interval, key N is said to be dead. This occurs at the + dead time (Tdea) so: + + Tdea = Tret + Iret + + Event 6: at some later time key N and its signatures can be removed + from the zone. This is the removal time Trem, given by: + + Trem >= Tdea + +3.2.3. Double-RRSIG Method + + As noted above, "Double-Signature" is simultaneous rollover of both + signature and key. The time line for a pure Double-Signature ZSK + rollover (the Double-RRSIG method) - where new signatures are + introduced, the key changed, and finally the old signatures removed - + is shown below: + + + + |1||2| |3| |4||5| |6||7| |8||9| |10| |11| + | | | | | | | | | | | + Key N | |<-Dsgn->| | |<-----------Lzsk-------->|<-Iret->| | + | |<---IpubG-->| |<-IpubK->| | | | | | + | | | | | | | | | | | + Key N+1 | | | | | | |<-IpubG->| | | | + | | | | | | | | | | | + Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem + + ---- Time ----> + + + Figure 3: Timeline for a Double-Signature ZSK rollover. + + + +Morris, et al. Expires January 2, 2011 [Page 14] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to publication in the zone (Event 2), some implementations may find + it convenient to create a pool of keys in one operation and draw from + that pool as required. For this reason, it is shown as a separate + event. Keys that are available for use but not published are said to + be generated. + + Event 2: key N is used to sign the zone but existing signatures are + retained. Although the new ZSK is not published in the zone at this + point, for analogy with the other ZSK rollover methods and because + this is the first time that key information is visible (albeit + indirectly through the created signatures) this time is called the + publish time (Tpub). + + Event 3: after the signing interval, Dsgn, all RRsets that need to be + signed have been signed by the new key. (As a result, all these + RRsets are now signed twice, once by the existing key and once by the + (still-absent) key N. + + Event 4: there is now a delay while the this information reaches all + validating resolvers that may have RRsets from the zone cached. This + interval is given by the expression: + + Dprp + TTLsig + + ...comprising the delay for the information to propagate through the + nameserver infrastructure plus the time taken for signature + information to expire from caches. + + Again in analogy with other key rollover methods, this is defined as + key N's ready time (Trdy) and the key is said to be in the ready + state. (Although the key is not in the zone, it is ready to be + used.) The interval between the publication and ready times is the + publication interval of the signature, IpubG, i.e. + + Trdy = Tpub + IpubG + + where + + IpubG = Dsgn + Dprp + TTLsig + + Event 5: at some later time the predecessor key is removed and the + key N added to the DNSKEY RRset. As all the RRs have signatures + created by the old and new keys, the records can still be + authenticated. This time is the active time (Tact) and the key is + now said to be active. + + + + +Morris, et al. Expires January 2, 2011 [Page 15] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Event 6: After IpubK - the publication interval of the key - the + newly added DNSKEY RRset has propagated through to all validating + resolvers. At this point the old signatures can be removed from the + zone. IpubK is given by: + + IpubK = Dprp + TTLkey + + Event 7: as before, at some later time thought must be given to + rolling the key. The first step is to publish signatures created by + the successor key (key N+1) early enough so that key N can be + replaced after it has been active for its scheduled lifetime. This + occurs at TpubS (the publication time of the successor), given by: + + TpubS <= Tact + Lzsk - IpubG + + Event 8: the signatures have propagated through the zone and the new + key could be added to the zone. This time is the ready time of the + successor (TrdyS). + + TrdyS = TpubS + IpubG + + ... where IpubG is as defined above. + + Event 9: at some later time key N is removed from the zone and the + successor key added. This is the retire time of the key (Tret). + + Event 10: The signatures must remain in the zone for long enough that + the new DNSKEY RRset has had enough time to propagate to all caches. + Once caches contain the new DNSKEY, the old signatures are no longer + of use and can be considered to be dead. The time at which this + occurs is the dead time (Tdea), given by: + + Tdea = Tret + Iret + + ... where Iret is the retire interval, given by: + + Iret = IpubK + + Event 11: At some later time the signatures can be removed from the + zone. Although the key has is not longer in the zone, this is + information associated with it and so the time can be regarded as the + key's remove time (Trem), given by: + + Trem >= Tdea + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 16] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + +3.3. Key-Signing Key Rollover Timelines + +3.3.1. Double-Signature Method + + The Double-Signature method (also knows as the double-DNSKEY method) + involves introducing the new KSK to the zone and waiting until its + presence has been registered by all validating resolvers. At this + point, the DS record in the parent is changed. Once that change has + propagated to all validating resolvers, the old KSK is removed. + + The timing diagram for such a rollover is: + + + + |1| |2| |3| |4| |5| |6| + | | | | | | + Key N | |<-Ipub->|<--->|<-Dreg->|<---------Lksk--- - - + | | | | | | + Key N+1 | | | | | | + | | | | | | + Tgen Tpub Trdy Tsub Tact + + ---- Time ----> + + (continued...) + + |7| |8| |9| |10| |11| |12| + | | | | | | + Key N - - -------------Lksk------->|<-Iret->| | + | | | | | | + Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - + | | | | | | + TpubS TrdyS TsubS Tret Tdea Trem + + ---- Time (cont) ----> + + + Figure 4: Timeline for a Double-Signature KSK rollover. + + Event 1: key N is generated at time Tgen. As before, although there + is no reason why the key cannot be generated immediately prior to + publication, some implementations may find it convenient to create a + central pool of keys and draw from it. For this reason, it is again + shown as a separate event. + + Event 2: key N is introduced into the zone; it is added to the DNSKEY + RRset, which is then signed by key N and all currently active KSKs. + (So at this point, the DNSKEY RRset is signed by both key N and its + + + +Morris, et al. Expires January 2, 2011 [Page 17] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + predecessor KSK. If other KSKs were active, it is signed by these as + well.) This is the publication time (Tpub); after this the key is + said to be published. + + Event 3: before it can be used, the key must be published for long + enough to guarantee that any validating resolver that has a copy of + the DNSKEY RRset from the zone in its cache will have a copy of the + RRset that includes this key: in other words, that any prior cached + information about the DNSKEY RRset has expired. + + The interval is the publication interval (Ipub) and, for the second + or subsequent KSKs in the zone, is given by: + + Ipub = Dprp + TTLkey + + ... where Dprp is the propagation delay for the zone and TTLkey the + TTL for the DNSKEY RRset. The time at which this occurs is the key's + ready time, Trdy, given by: + + Trdy = Tpub + Ipub + + Event 4: at some later time, the DS RR corresponding to the new KSK + is submitted to the parent zone for publication. This time is the + submission time, Tsub. + + Event 5: the DS record is published in the parent zone. As this is + the point at which all information for authentication - both DNSKEY + and DS record - is available in the two zones, it is the active time + of the key: + + Tact = Tsub + Dreg + + ... where Dreg is the registration delay, the time taken after the DS + record has been received by the parent zone manager for it to be + placed in the zone. (Parent zones are often managed by different + entities, and this term accounts of the organisational overhead of + transferring a record.) + + Event 6: at some time later, all validating resolvers that have the + DS RRset cached will have a copy that includes the new DS record. + For the second or subsequent DS records, this interval is given by + the expression: + + DprpP + TTLds + + ... where DprpP is the propagation delay in the parent zone and TTLds + the TTL assigned to DS records in that zone. + + + + +Morris, et al. Expires January 2, 2011 [Page 18] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + In the case of the first DS record for the zone in question, the + expression is slightly different because it is not information about + a DS RRset that may be cached, it is information about its absence. + In this case, the interval is: + + DprpP + IngcP + + where IngcP is the negative cache interval from the zone's SOA + record, calculated according to [RFC2308] as the minimum of the TTL + of the parent SOA record itself (TTLsoaP), and the "minimum" field in + the record's parameters (SOAminP), i.e. + + IngcP = min(TTLsoaP, SOAminP) + + Event 7: while key N is active, thought needs to be given to its + successor (key N+1). At some time before the scheduled end of the + KSK lifetime, the successor KSK is introduced into the zone and is + used to sign the DNSKEY RRset. (As before, this means that the + DNSKEY RRset is signed by both the current and successor KSK.) This + is the publication time of the successor key, TpubS. + + Event 8: after an interval Ipub, the successor key becomes ready (in + that all validating resolvers that have a copy of the DNSKEY RRset + have a copy of this key). This is the successor ready time, TrdyS. + + Event 9: at the successor submission time (TsubS), the DS record + corresponding to the successor key is submitted to the parent zone. + + Event 10: the successor DS record is published in the parent zone and + the current DS record withdrawn. The current key is said to be + retired and the time at which this occurs is Tret, given by: + + The relationships between these times are: + + TpubS <= Tact + Lksk - Dreg - Ipub + + Tret = Tact + Lksk + + ... where Lksk is the scheduled lifetime of the KSK. + + Event 11: key N must remain in the zone until any validators that + have the DS RRset cached have a copy of the DS RRset containing the + new DS record. This interval is the retire interval, given by: + + Iret = DprpP + TTLds + + ... where DprpP is the propagation delay in the parent zone and TTLds + the TTL of a DS record. + + + +Morris, et al. Expires January 2, 2011 [Page 19] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + As the key is no longer used for anything, it can also be said to be + dead, in which case: + + Tdea = Tret + Iret + + Event 12: at some later time, key N is removed from the zone (at the + remove time Trem); the key is now said to be removed. + + Trem >= Tdea + +3.3.2. Double-DS Method + + The Double-DS method is the reverse of the Double-Signature method is + that it is the DS record that is pre-published (in the parent), and + not the DNSKEY. + + The timeline for the key rollover is shown below: + + + + |1| |2| |3| |4| |5| |6| + | | | | | | + Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - + | | | | | | + Key N+1 | | | | |<---->|<--Dreg+IpubP- - - + | | | | | | + Tgen Tsub Tpub Trdy Tact TsubS + + ---- Time ----> + + (continued...) + + |7| |8| |9| |10| + | | | | + Key N - - -----Lksk---------->|<-Iret->| | + | | | | + Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - + | | | | + TrdyS Tret Tdea Trem + + ---- Time ----> + + + Figure 5: Timeline for a Double-DS KSK rollover. + + Event 1: key N is generated at time Tgen. As before, although there + is no reason why the key cannot be generated immediately prior to + publication, some implementations may find it convenient to create a + + + +Morris, et al. Expires January 2, 2011 [Page 20] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + central pool of keys and draw from it. For this reason, it is again + shown as a separate event. + + Event 2: the DS record corresponding to key N is submitted for + publication in the parent zone. This time is the submission time + (Tsub). + + Event 3: after the registration delay, Dreg, the DS record is + published in the parent zone. This is the publication time Tpub, + given by: + + Tpub = Tsub + Dreg + + Event 4: at some later time, any validating resolver that has copies + of the DS RRset in its cache will have a copy of the DS record for + key N. At this point, key N, if introduced into the DNSKEY RRset, + could be used to validate the zone. For this reason, this time is + known as the key's ready time, Trdy, and is given by: + + Trdy = Tpub + IpubP + + IpubP is the parent publication interval and is given by the + expression: + + IpubP = DprpP + TTLds + + ... where DprpP is the propagation delay in the parent zone and TTLds + the TTL assigned to DS records in that zone. + + Event 5: at some later time, the key rollover takes place. The + predecessor key is withdrawn from the DNSKEY RRset and the new key + (key N) introduced and used to sign the RRset. + + As both DS records have been in the parent zone long enough to ensure + that they are in the cache of any validating resolvers that have the + DS RRset cached, the zone can be authenticated throughout the + rollover - either the resolver has a copy of the DNSKEY RRset (and + associated RRSIGs) authenticated by the predecessor key, or it has a + copy of the updated RRset authenticated with the new key. + + This time is the key's active time (Tact) and at this point the key + is said to be active. + + Event 6: at some point thought must be given to key replacement. The + DS record for the successor key must be submitted to the parent zone + at a time such that when the current key is withdrawn, any validating + resolver that has DS records in its cache will have data about the DS + record of the successor key. The time at which this occurs is the + + + +Morris, et al. Expires January 2, 2011 [Page 21] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + submission time of the successor, given by: + + TsubS <= Tact + Lksk - IpubP - Dreg + + ... where Lksk is the lifetime of the KSK. + + Event 7: the successor key (key N+1) enters the ready state i.e. its + DS record is now in the caches of all validating resolvers that have + the parent DS RRset cached. (This is the ready time of the + successor, TrdyS.) + + Event 8: when the current key has been active for its lifetime + (Lksk), the current key is removed from the DNSKEY RRset and the + successor key added; the RRset is then signed with the successor key. + This point is the retire time of the key, Tret, given by: + + Tret = Tact + Lksk + + Event 9: at some later time, all copies of the old DNSKEY RRset have + expired from caches and the old DS record is no longer needed. This + is called the dead time, Tdea, and is given by: + + Tdea = Tret + Iret + + ... where Iret is the retire interval, given by: + + Iret = Dprp + TTLkey + + As before, this term includes the time taken to propagate the RRset + change through the master-slave hierarchy and the time take for the + DNSKEY RRset to expire from caches. + + Event 10: at some later time, the DS record is removed from the + parent zone. This is the removal time (Trem), given by: + + Trem >= Tdea + +3.3.3. Double-RRset Method + + In the Double-RRset method, both the DS and DNSKEY records are + changed at the same time, so for a period the zone can be + authenticated with either key. The advantage of this method is its + applicability in cases where zone management policy requires overlap + of authentication keys during a roll. + + The timeline for this rollover is shown below: + + + + + +Morris, et al. Expires January 2, 2011 [Page 22] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + |1| |2| |3| |4| |5| |6| |7| + | | | | | | | + Key N | |<-Dreg->|<-----Lksk----->|<-Iret->| | + | | | | | | | + Key N+1 | | | |<-Dreg->|<-----Lksk-- - - + | | | | | | | + Tgen Tpub Tact TpubS Tret Tdea Trem + + ---- Time ----> + + + Figure 6: Timeline for a Double-RRset KSK rollover. + + Event 1: key N is created at time Tgen and thereby immediately + becomes generated. As before, although there is no reason why the + key cannot be generated immediately prior to publication, some + implementations may find it convenient to create a central pool of + keys and draw from it. For this reason, it is again shown as a + separate event. + + Event 2: the key is added to and used for signing the DNSKEY RRset + and is thereby published in the zone. At the same time the + corresponding DS record is submitted to the parent zone for + publication. This time is the publish time (Tpub) and the key is now + said to be published. + + Event 3: after Dreg, the registration delay, the DS record is + published in the parent zone. At this point, the zones have all the + information needed for a validating resolver to authenticate the + zone, although the information may not yet have reached all + validating resolver caches. This time is the active time (Tact) and + the key is said to be active. + + Tact = Tpub + Dreg + + Event 4: at some point we need to give thought to key replacement. + The successor key must be introduced into the zone (and its DS record + submitted to the parent) at a time such that it becomes active when + the current key has been active for its lifetime, Lksk. This time is + TpubS, the publication time of the successor key, and is given by: + + TpubS <= Tact + Lksk - Dreg + + ... where Lksk is the lifetime of the KSK. + + Event 5: the successor key's DS record appears in the parent zone and + the successor key becomes active. At this point, the current key + becomes retired. This occurs at Tret, given by: + + + +Morris, et al. Expires January 2, 2011 [Page 23] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Tret = Tact + Lksk + + Event 6: the current DNSKEY and DS record must be retained in the + zones until any any validating resolver that has cached the DNSKEY + and/or DS RRsets will have a copy of the data for the successor key. + At this point the current key information is dead, as any validating + resolver can perform authentication using the successor key. This is + the dead time, Tdea, given by: + + Tdea = Tret + Iret + + ... where Iret is the retire interval. This depends on how long both + the successor DNSKEY and DS records take to propagate through the + nameserver infrastructure and thence into validator caches. These + delays are the publication intervals of the child and parent zones + respectively, so a suitable expression for Iret is: + + Iret = max(IpubP, IpubC) + + IpubC is the publication interval of the DNSKEY in the child zone, + IpubP that of the DS record in the parent. + + The child term comprises two parts - the time taken for the + introduction of the DNSKEY record to be propagated to the downstream + secondary servers (= DprpC, the child propagation delay) and the time + taken for information about the DNSKEY RRset to expire from the + validating resolver cache, i.e. + + IpubC = DprpC + TTLkey + + TTLkey is the TTL for a DNSKEY record in the child zone. The parent + term is similar: + + IpubP = DprpP + TTLds + + DprpP the propagation delay in the parent zone and TTLds the TTL for + a DS record in the parent zone. + + Event 7: at some later time, the DNSKEY record can be removed from + the child zone and a request can be made to remove the DS record from + the parent zone. This is the removal time, Trem and is given by: + + Trem >= Tdea + + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 24] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + +3.3.4. Interaction with Configured Trust Anchors + + Although the preceding sections have been concerned with rolling KSKs + where the trust anchor is a DS record in the parent zone, zone + managers may want to take account of the possibility that some + validating resolvers may have configured trust anchors directly. + + Rolling a configured trust anchor is dealt with in [RFC5011]. It + requires introducing the KSK to be used as the trust anchor into the + zone for a period of time before use, and retaining it (with the + "revoke" bit set) for some time after use. The Double-Signature and + Double-RRset methods can be adapted to include [RFC5011] + recommendations so that the rollover will also be signalled to + validating resolvers with configured trust anchors. (The + recommendations are not suitable for the Double-DS method. + Introducing the new key early and retaining the old key after use + effectively converts it into a form of Double-RRset.) + +3.3.4.1. Addition of KSK + + When the new key is introduced, the publication interval (Ipub) in + the Double-Signature method should also be subject to the condition: + + Ipub >= max(30 days, TTLkey) + + ... where the right had side of the expression is the add hold-down + time defined in section 2.4.1 of [RFC5011]. + + In the Double-RRSIG method, the key should not be regarded as being + active until the add hold-down time has passed. In other words, the + following condition should be enforced: + + Tact >= Tpub + max(30 days, TTLkey) + + (Effectively, this means extending the lifetime of the key by an + appropriate amount.) + +3.3.4.2. Removal of KSK + + The timeline for the removal of the key in both methods is modified + by introducing a new state, "revoked". When the key reaches the end + of the retire period, instead of being declared "dead", it is + revoked; the "revoke" bit is set on the DNSKEY RR and is published in + (and used to sign) the DNSKEY RRset. The key is maintained in this + state for the "revoke" interval, Irev, given by: + + + + + + +Morris, et al. Expires January 2, 2011 [Page 25] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Irev >= 30 days + + ... 30 days being the [RFC5011] remove hold-down time. After this + time, the key is dead and can be removed from the zone when + convenient. + +3.3.5. Introduction of First KSK + + There is an additional consideration when introducing a KSK into a + zone for the first time, and that is that no validating resolver + should be in a position where it can access the trust anchor before + the KSK appears in the zone. To do so will cause the validating + resolver to declare the zone to be bogus. + + This is important: in the case of a secure parent, it means ensuring + that the DS record is not published in the parent zone until there is + no possibility that a validating resolver can obtain the record yet + not be able to obtain the corresponding DNSKEY. In the case of an + insecure parent, i.e. the initial creation of a new security apex, it + is important to not configure trust anchors in validating resolvers + until the DNSKEY RRset has had sufficient time to propagate. In both + cases, this time is the trust anchor availability time (Ttaa) given + by: + + Ttaa >= Tpub + IpubC + + where + + IpubC = DprpC + TTLkeyC + + or + + IpubC = DprpC + IngcC + + The first expression applies if there was previously a DNSKEY RRset + in the child zone, the expression for IpubC including the TTLkeyC + term to account for the time taken for that RRset to expire from + caches. (It is possible that the zone was signed but that the trust + anchor had not been submitted to the parent.) + + If the introduction of the KSK caused the appearance of the first + DNSKEY RRset in the child zone, the second expression applies in + which the TTLkeyC term is replaced by Ingc to allow for the effect of + negative caching. + + As before, IngcC is the negative cache interval from the child zone's + SOA record, calculated according to [RFC2308] as the minimum of the + TTL of the SOA record itself (TTLsoaC), and the "minimum" field in + + + +Morris, et al. Expires January 2, 2011 [Page 26] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + the record's parameters (SOAminC), i.e. + + IngcC = min(TTLsoaC, SOAminC) + + +4. Standby Keys + + Although keys will usually be rolled according to some regular + schedule, there may be occasions when an emergency rollover is + required, e.g. if the active key is suspected of being compromised. + The aim of the emergency rollover is to allow the zone to be re- + signed with a new key as soon as possible. As a key must be in the + ready state to sign the zone, having at least one additional key (a + standby key) in this state at all times will minimise delay. + + In the case of a ZSK, a standby key only really makes sense with the + Pre-Publication method. A permanent standby DNSKEY RR should be + included in zone or successor keys could be introduced as soon as + possible after a key becomes active. Either way results in an + additional ZSK in the DNSKEY RRset that can immediately be used to + sign the zone if the current key is compromised. + + (Although in theory the mechanism could be used with both the Double- + Signature and Double-RRSIG methods, it would require Pre-Publication + of the signatures. Essentially, the standby key would be permanently + active, as it would have to be periodically used to renew signatures. + Zones would also permanently require two sets of signatures, + something that could have a performance impact in large zones.) + + A standby key can also be used with the Double-Signature and + Double-DS methods of rolling a KSK. (The idea of a standby key in + the Double-RRset effectively means having two active keys.) The + Double-Signature method requires that the standby KSK be included in + the DNSKEY RRset; rolling the key then requires just the introduction + of the DS record in the parent. (Note that the DNSKEY should also be + used to sign the DNSKEY RRset. As the RRset and its signatures + travel together, merely adding the DNSKEY does not provide the + desired time saving; to be used in a rollover requires that the + DNSKEY RRset be signed with the standby key, and this introduces a + delay whilst the RRset and its signatures propagate to the caches of + validating resolvers. There is no time advantage over introducing a + new DNSKEY and signing the RRset with it at the same time.) + + In the Double-DS method of rolling a KSK, it is not a standby key + that is present, it is a standby DS record in the parent zone. + Whatever algorithm is used, the standby item of data can be + introduced as a permanent standby, or be a successor introduced as + early as possible. + + + +Morris, et al. Expires January 2, 2011 [Page 27] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + +5. Algorithm Considerations + + The preceding sections have implicitly assumed that all keys and + signatures are created using a single algorithm. However, [RFC4035] + (section 2.4) states that "There MUST be an RRSIG for each RRset + using at least one DNSKEY of each algorithm in the zone apex DNSKEY + RRset". + + Except in the case of an algorithm rollover - where the algorithms + used to create the signatures are being changed - there is no + relationship between the keys of different algorithms. This means + that they can be rolled independently of one another. In other + words, the key rollover logic described above should be run + separately for each algorithm; the union of the results is included + in the zone, which is signed using the active key for each algorithm. + + +6. Summary + + For ZSKs, "Pre-Publication" is generally considered to be the + preferred way of rolling keys. As shown in this document, the time + taken to roll is wholly dependent on parameters under the control of + the zone manager. + + In contrast, "Double-RRset" is the most efficient method for KSK + rollover due to the ability to have new DS records and DNSKEY RRsets + propagate in parallel. The time taken to roll KSKs may depend on + factors related to the parent zone if the parent is signed. For + zones that intend to comply with the recommendations of [RFC5011], in + virtually all cases the rollover time will be determined by the + RFC5011 "add hold-down" and "remove hold-down" times. It should be + emphasized that this delay is a policy choice and not a function of + timing values and that it also requires changes to the rollover + process due to the need to manage revocation of trust anchors. + + Finally, the treatment of emergency key rollover is significantly + simplified by the introduction of stand-by keys as standard practice + during all types of rollovers. + + +7. IANA Considerations + + This memo includes no request to IANA. + + +8. Security Considerations + + This document does not introduce any new security issues beyond those + + + +Morris, et al. Expires January 2, 2011 [Page 28] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. + + +9. Acknowledgements + + The authors gratefully acknowledge help and contributions from Roy + Arends and Wouter Wijngaards. + + +10. Change History + + o draft-morris-dnsop-dnssec-key-timing-02 + * General restructuring. + * Added descriptions of more rollovers (IETF-76 meeting). + * Improved description of key states and removed diagram. + * Provided simpler description of standby keys. + * Added section concerning first key in a zone. + * Moved [RFC5011] to a separate section. + * Various nits fixed (Alfred Hones, Jeremy Reed, Scott Rose, Sion + Lloyd, Tony FinchX). + + o draft-morris-dnsop-dnssec-key-timing-01 + * Use latest boilerplate for IPR text. + * List different ways to roll a KSK (acknowledgements to Mark + Andrews). + * Restructure to concentrate on key timing, not management + procedures. + * Change symbol notation (Diane Davidowicz and others). + * Added key state transition diagram (Diane Davidowicz). + * Corrected spelling, formatting, grammatical and style errors + (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya). + * Added note that in the case of multiple algorithms, the + signatures and rollovers for each algorithm can be considered as + more or less independent (Alfred Hoenes). + * Take account of the fact that signing a zone is not atomic + (Chris Thompson). + * Add section contrasting pre-publication rollover with double + signature rollover (Matthijs Mekking). + * Retained distinction between first and subsequent keys in + definition of initial publication interval (Matthijs Mekking). + + o draft-morris-dnsop-dnssec-key-timing-00 + Initial draft. + + +11. References + + + + + +Morris, et al. Expires January 2, 2011 [Page 29] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + +11.1. Normative References + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) + Trust Anchors", RFC 5011, September 2007. + +11.2. Informative References + + [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", + RFC 4641, September 2006. + + +Appendix A. List of Symbols + + The document defines a number of symbols, all of which are listed + here. All are of the form: + + All symbols used in the text are of the form: + + + + where: + + is an upper-case character indicating what type the symbol is. + Defined types are: + + D delay: interval that is a feature of the process + + I interval between two events + + L lifetime: interval set by the zone manager + + + + + + +Morris, et al. Expires January 2, 2011 [Page 30] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + SOA parameter related to SOA RR + + T a point in time + + TTL TTL of a record + + T and I are self-explanatory. D, and L are also time periods, but + whereas I values are intervals between two events (even if the events + are defined in terms of the interval, e.g. the dead time occurs + "retire interval" after the retire time), D, and L are fixed + intervals. An "L" interval (lifetime) is chosen by the zone manager + and is a feature of policy. A "D" interval (delay) is a feature of + the process, probably outside control of the zone manager. SOA and + TTL are used just because they are common terms. + + is lower-case and defines what object or event the variable is + related to, e.g. + + act active + + ngc negative cache + + pub publication + + Finally, is a capital letter that distinguishes between the + same variable applying to different instances of an object and is one + of: + + C child + + G signature + + K key + + P parent + + S successor + + The list of variables used in the text is: + + Dprp Propagation delay. The amount of time for a change made at + a master nameserver to propagate to all the slave + nameservers. + + DprpC Propagation delay in the child zone. + + + + + + +Morris, et al. Expires January 2, 2011 [Page 31] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + DprpP Propagation delay in the parent zone. + + Dreg Registration delay. As a parent zone is often managed by a + different organisation to that managing the child zone, the + delays associated with passing data between zones is + captured by this term. + + Dskw Clock skew. The maximum difference in time between the + signing system and the resolver. + + Dsgn Signing delay. After the introduction of a new ZSK, the + amount of time taken for all the RRs in the zone to be + signed with it. + + Ingc Negative cache interval. + + IngcP Negative cache interval of the child zone. + + IngcP Negative cache interval of the parent zone. + + Ipub Publication interval. The amount of time that must elapse + after the publication of a key before it can be considered + to have entered the ready state. + + IpubC Publication interval in the child zone. + + IpubG Publication interval for the signature. + + IpubK Publication interval for the key. + + IpubP Publication interval in the parent zone. + + Iret Retire interval. The amount of time that must elapse after + a key enters the retire state for any signatures created + with it to be purged from validating resolver caches. + + Irev Revoke interval. The amount of time that a KSK must remain + published with the revoke bit set to satisfy [RFC5011] + considerations. + + Lksk Lifetime of a key-signing key. This is the intended amount + of time for which this particular KSK is regarded as the + active KSK. Depending on when the key is rolled-over, the + actual lifetime may be longer or shorter than this. + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 32] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Lzsk Lifetime of a zone-signing key. This is the intended + amount of time for which the ZSK is used to sign the zone. + Depending on when the key is rolled-over, the actual + lifetime may be longer or shorter than this. + + Lsig Lifetime of a signature: the difference in time between the + signature's expiration time and the time at which the + signature was created. (Note that this is not the + difference between the signature's expiration and inception + times: the latter is usually set a small amount of time + before the signature is created to allow for clock skew + between the signing system and the validating resolver.) + + SOAmin Value of the "minimum" field from an SOA record. + + SOAminC Value of the "minimum" field from an SOA record in the + child zone. + + SOAminP Value of the "minimum" field from an SOA record in the + parent zone. + + Tact Active time of the key; the time at which the key is + regarded as the principal key for the zone. + + TactS Active time of the successor key. + + Tdea Dead time of a key. Applicable only to ZSKs, this is the + time at which any record signatures held in validating + resolver caches are guaranteed to be created with the + successor key. + + Tgen Generate time of a key. The time that a key is created. + + Tpub Publish time of a key. The time that a key appears in a + zone for the first time. + + TpubS Publish time of the successor key. + + Trem Removal time of a key. The time at which a key is removed + from the zone. + + Tret Retire time of a key. The time at which a successor key + starts being used to sign the zone. + + Trdy Ready time of a key. The time at which it can be + guaranteed that validating resolvers that have key + information from this zone cached have a copy of this key + in their cache. (In the case of KSKs, should the + + + +Morris, et al. Expires January 2, 2011 [Page 33] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + validating resolvers also have DS information from the + parent zone cached, the cache must include information + about the DS record corresponding to the key.) + + TrdyS Ready time of a successor key. + + Tsub Submit time - the time at which the DS record of a KSK is + submitted to the parent. + + TsubS Submit time of the successor key. + + TTLds Time to live of a DS record (in the parent zone). + + TTLkey Time to live of a DNSKEY record. + + TTLkeyC Time to live of a DNSKEY record in the child zone. + + TTLsoa Time to live of a SOA record. + + TTLsoaC Time to live of a SOA record in the child zone. + + TTLsoaP Time to live of a SOA record in the parent zone. + + TTLsig Time to live of an RRSIG record. + + Ttaa Trust anchor availability time. The time at which a trust + anchor record can be made available when a KSK is first + introduced into a zone. + + +Authors' Addresses + + Stephen Morris + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + Phone: +1 650 423 1300 + Email: stephen@isc.org + + + + + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 34] + +Internet-Draft DNSSEC Key Timing Considerations July 2010 + + + Johan Ihren + Netnod + Franzengatan 5 + Stockholm, SE-112 51 + Sweden + + Phone: +46 8615 8573 + Email: johani@autonomica.se + + + John Dickinson + Sinodun Internet Technologies Ltd + Stables 4 Suite 11, Howbery Park + Wallingford, Oxfordshire OX10 8BA + UK + + Phone: +44 1491 818120 + Email: jad@sinodun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morris, et al. Expires January 2, 2011 [Page 35] +