Internet Engineering Task Force S. Morris Internet-Draft Nominet Intended status: Informational J. Ihren Expires: August 21, 2009 Autonomica J. Dickinson February 17, 2009 DNSSEC Key Timing Considerations draft-morris-dnsop-dnssec-key-timing-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 21, 2009. Copyright Notice Copyright (c) 2009 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. Morris, et al. Expires August 21, 2009 [Page 1] Internet-Draft DNSSEC Key Timing Considerations February 2009 Abstract RFC 4641 gives a detailed overview of the operational considerations involved in running a DNSSEC-secured zone, including key rollovers. This document expands on the previous work, and discusses timing considerations in greater depth. It explicitly identifies the relationships between the various time parameters, and gives a suggested algorithm for key rollover in a DNSSEC-secured zone. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Zone-Signing Keys . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Emergency Zone-Signing Keys . . . . . . . . . . . . . . . 7 2.2.1. Emergency Key Replacement . . . . . . . . . . . . . . 7 2.2.2. Emergency Key Use . . . . . . . . . . . . . . . . . . 8 2.3. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Actual and Estimated Times . . . . . . . . . . . . . . 9 2.3.2. Practical Timing Considerations . . . . . . . . . . . 9 2.3.3. ZSK Management Procedure . . . . . . . . . . . . . . . 10 3. Key-Signing Keys . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Emergency Key-Signing Keys . . . . . . . . . . . . . . . . 15 3.3. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 15 3.4.1. Actual and Estimated Times . . . . . . . . . . . . . . 15 3.4.2. Practical Timing Considerations . . . . . . . . . . . 16 3.4.3. KSK Management Procedure . . . . . . . . . . . . . . . 16 4. Running the Key Management Procedures . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Morris, et al. Expires August 21, 2009 [Page 2] Internet-Draft DNSSEC Key Timing Considerations February 2009 1. Introduction When a zone is secured with DNSSEC, [RFC4641] recommends that the keys used to sign the zone are periodically replaced (or "rolled over"). In order to implement this recommendation, the keys need to be managed in order to allow them to be introduced into and removed from the zone at the appropriate times. Considerations that must be taken into account are: o Key and signature records are not only held at the authoritative nameserver; they are also cached at client resolvers. The data on these can be interlinked, e.g. a validator may try to validate a signature retrieved from a cache with a key obtained separately. o To allow for emergency re-signing, additional keys (over and above those used to sign the zone) need to be present. 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), stale key records must be periodically removed. (For the same reason, the number of emergency 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. Management policy, e.g. how long a key is used for, also needs to be taken into account. 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. In other words, although key management logic enforces policy, it may not enforce it strictly. 1.1. Terminology The terminology used in this document is as defined in [RFC4033] and [RFC4641]. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Morris, et al. Expires August 21, 2009 [Page 3] Internet-Draft DNSSEC Key Timing Considerations February 2009 document are to be interpreted as described in [RFC2119]. 2. Zone-Signing Keys 2.1. Key Timeline The following diagram shows the time line of a particular ZSK (zone- signing key) and its replacement by its successor. 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. |1| |2| |3| |4| |5| |6| |7| |8| |9| | | | | | | | | | Key N | |<-Ip->|<--->|<-------Lz------->|<-It->|<--->| | | | | | | | | | Key N+1 | | | | |<-Ip->|<--->|<--------Lz-- - - | | | | | | | | | Tg Tp Tr Ta Tps Tt Td Tm ---- Time ----> Timeline for a ZSK rollover. Figure 1 Event 1: key N is generated at the generate time (Tg). 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 generated but not published are said to be in the generate state. 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. Note that key N is not yet used to sign records. The time at which this occurs is the key's publication time (Tp), and the key is now in the published state. Event 3: before it can be used, the key must stay in the published state 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 record: in other words, that any Morris, et al. Expires August 21, 2009 [Page 4] Internet-Draft DNSSEC Key Timing Considerations February 2009 prior cached information about the DNSKEY RRset has expired. The interval is the publication interval (Ip) and, for the second or subsequent keys in the zone, is given by: Ip = TTLkey + Dp Here, TTLkey is the time-to-live (TTL) for the DNSKEY records in the zone. The other term is Dp (the propagation delay), which is included because of the finite time taken for any change introduced at the master to replicate to all slave servers. The delay depends on the depth of the master-slave hierarchy. In the case of the first key in the zone, Ip is slightly different because it is not information about a DNSKEY RRset that may be cached at downstream validators, it is information about its absence. In this case: Ip = C + Dp where C is the negative cache time from the zone's SOA record, calculated as described in [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. C = min(TTLsoa, SOAmin) The two expressions for Ip may be conveniently combined as: Ip = max(TTLkey, C) + Dp After a delay of Ip, the key is in the ready state and can be used to sign records. The time at which this event occurs is the key's ready time (Tr), which is given by: Tr = Tp + Ip Event 4: at some later time, the key is used to sign the zone. This point is the activation time (Ta) and after this, the key is said to be in the active state. Event 5: while this key is active, thought must be given to its successor. As with the introduction of the present key into the zone, the successor key will need to be published at least Ip before it is used. Denoting the publication time of the successor key by Tps, then: Morris, et al. Expires August 21, 2009 [Page 5] Internet-Draft DNSSEC Key Timing Considerations February 2009 Tps <= Ta + Lz - Ip Here, Lz is the length of time for which a ZSK will be used (the ZSK lifetime). It should be noted that unlike the publication interval, Lz is not determined by timing logic, but by key management policy. Lz 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 lives for slightly more or less than Lz. Event 6: while the present ZSK is still active, its successor moves into the ready state. 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: Tt = Ta + Lz This point in time is the retire time (Tt) of key N; after this the 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 resolvers still have RRSIG records in their cache that were created using the key. (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 (It) given by: It = TTLsig + Dp TTLsig is the TTL of the RRSIG records and Dp the propagation delay, the latter being included in the equation for the same reason as given in the description of event 3. Once this time has passed, the key can be considered dead. This time is the dead time (Td), given by: Td = Tt + It 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 (Tm), given by: Morris, et al. Expires August 21, 2009 [Page 6] Internet-Draft DNSSEC Key Timing Considerations February 2009 Tm >= Td 2.2. Emergency Zone-Signing Keys Although ZSKs will usually be generated according to some regular schedule, there may be occasions when an emergency ZSK rollover is required, e.g. if a key is suspected of being compromised. The aim of the emergency key rollover is to allow the zone to be re-signed with the new key as soon as possible. As a key must be in the ready state to sign the zone, it may be advisable to have at least one spare ZSK in that state at all times. 2.2.1. Emergency Key Replacement One way to handle this is to regard successor keys as emergency keys, and to introduce them in the zone as early as possible. A modification of Figure 1 illustrates this: |1| |2| |3| |4| | | | | Key N - - - -- Lz ------------->| | | | | | Key N+1 - --------------------->|<-----Lz------>| | | | | Key N+2 |<--Ip-->|<---------------------->|<--Lz-- - - | | | | ---- Time ----> Timeline showing emergency key replacement. Figure 2 In this figure, it is assumed that key N is initially in the active state and that key N+1 is in the ready state. Key N+1 is the successor to key N but is regarded as the emergency key until the time comes to use it to sign the zone. Event 1: At least Ip (publication interval) before key N's retire time, key N+2 is published in the zone. Event 2: key N+2 moves into the ready state. Event 3: key N is retired and key N+1 becomes active (as described in figure 1, events 7 - 9). Key N+2 is now regarded as the emergency Morris, et al. Expires August 21, 2009 [Page 7] Internet-Draft DNSSEC Key Timing Considerations February 2009 key. Event 4: key N+1 is retired and key N+2 becomes the current key. (By this time, key N+3 will have been published and be in the ready state.) The above illustrates one way of handling emergency keys. An equally valid alternative would be to have a permanent emergency key. In this scheme, a key is published in the zone as an emergency key: unless it needs to be used in an emergency, it is never used to sign the zone. Instead, active keys are replaced by their successors as shown in Figure 1. 2.2.2. Emergency Key Use An emergency key rollover could be required at any time. Referring back to Figure 2, should an emergency rollover be required between events 2 and 3, the sequence would happen as previously described: there is a already key (key N+2) ready to take over as the emergency key when the current emergency key becomes active. In the worst case though, it may be required that the system run without an emergency key for a while. For example, if a key rollover was required between events 3 and 4 in Figure 2, the timeline would look like: |3a| |3b| | | Key N+1 - --- Lz --->| | | | Key N+2 - ---------->|<----------Lz----- - - | | Key N+3 |<--Ip-->|<-------- - - | | ---- Time ----> Timeline showing emergency key rollover. Figure 3 In the above figure, the interval shown lies between events 3 and 4 in Figure 2, the events being labelled 3a and 3b to highlight this. Here it is assumed that key N+1 is initially in the active state and that the single emergency key (N+2) is in the ready state. It is well before the active key's retire time, so there are only these two Morris, et al. Expires August 21, 2009 [Page 8] Internet-Draft DNSSEC Key Timing Considerations February 2009 ZSKs in the zone. The events are: Event 3a: an emergency ZSK rollover is required. Key N+1 is retired and key N+2 becomes active. At this time, key N+3 (which will ultimately become the new emergency key) is published in the zone. Event 3b: key N+3 moves into the ready state, after which it can be used to replace key N+1 should the need arise. Between events 3a and 3b however, only the active key (key N+2) can be used to sign the zone. If a second emergency arises in this interval, the active key cannot be replaced: key rollover must wait until the new emergency key (N+3) becomes ready. Of course, this can be mitigated by having a number of emergency keys available, but how many is a matter of policy; there is a need to weigh the likelihood of a key compromise against the number of keys required. 2.3. Key Rollover Logic 2.3.1. Actual and Estimated Times In the above discussions, mention has been made of a number of significant times in the life of a key, e.g. publication time, activation time etc. At any particular time, the key is in one and only one state. The time at which it entered that state (and the time at which it entered all past states) are actual times. All future times are estimated times. For example, although the retire time of an active key is "activation time + key lifetime", until the key actually makes the transition into the retired state (by no longer being used to sign the zone), the retire time is only an estimate of the retire time: it may change depending on events. 2.3.2. Practical Timing Considerations Section Section 2.1 gave the theoretical timings for the entry of the ZSK to different states. The most critical transitions are between the publish and ready states, and between the retired and dead states. In both cases, a premature transition could lead to signatures not being validated. Adding a safety margin is therefore prudent. Such a margin takes in to account small uncertainties in timings as well as providing the implementation with robustness. The former could be due to factors such as the clocks on the server and validator running at slightly different rates so leading to a discrepancy in the calculation of intervals (interval skew). Adding robustness is just good management practice: the calculations above show when the key should be in the ready state - a safety margin provides increased certainty that all Morris, et al. Expires August 21, 2009 [Page 9] Internet-Draft DNSSEC Key Timing Considerations February 2009 parties agree that this is the case. In practical terms, adding a safety margin means replacing Ip and It in the equations above by Ip' and It' where: Ip' = Ip + Sp It' = It + St Sp is the publish safety margin and St the retire safety margin. At minimum they should be of the order of a few seconds to account for the interval skew; in practice, they are likely to be much greater, of the order of TTLsig. 2.3.3. ZSK Management Procedure The following section describes the procedure for maintaining ZSKs. It handles key rollover - both scheduled and emergency - as well as flagging which keys should be published in preparation for use in signing the zone. The following is assumed: 1. Information about keys is held in some data store. The information includes the state of each key and the times associated with each state change for each key. 2. There is only one active ZSK at any one time. 3. The procedure is run on a regular basis (at intervals of Ir) that depends on the interval between events in the timeline in Figure 1. (This is discussed further below.) In the following discussion, "now()" is the time at which the procedure is run. Also defined is Nze as the number of emergency ZKSs required to be able to immediately roll at any time for emergency reasons. A likely value is: Nze = 1 1. For all keys in the data store, calculate the estimated time of entering the next stage using the relationships described above. 2. If this procedure is being run as part of an emergency rollover, set the estimated retirement time for the active key(s) as now(). (In this way, an emergency key rollover requires no special processing: it is merely the early retirement of the active key.) Morris, et al. Expires August 21, 2009 [Page 10] Internet-Draft DNSSEC Key Timing Considerations February 2009 3. For each retired key, if now() >= Td, mark the key as dead. (Or remove it from the data store. Either way, this key is no longer of use and will never be used again.) 4. For each published key, if now() >= Tr, mark the key as ready. 5. If now() is within (Ip + Ir) of the estimated retire time of the active key (Ir being the interval between runs of the procedure) AND the number of keys in the publish and ready states combined is less than (1 + Nze), move a number of keys equal to the difference between these two values from the generate state into the publish state. (This step ensures that when the active key is retired, there is a key to replace it as well as the desired number of emergency keys in the ready state.) The term Ir appears here because to avoid a policy violation (i.e. a delay in retiring the active key) this action must occur at least Ip before the estimated retire time of the key. As the procedure is run at intervals, the only way to guarantee this is to add a margin equal to the run interval. 6. If now() is earlier than the retire time of the active key, exit. (Note "earlier"; if an emergency rollover is taking place, the retirement time of the active key will be equal to now() due to the processing of step 2.) 7. Check whether there are keys in the ready state. If not, the currently active key cannot be retired and the procedure will have to wait until one or more keys become ready. In this case, exit the procedure. 8. Mark the active key as retired. 9. Mark one of the ready keys as active. After this procedure, all keys in the publish, ready, active and retire states should be published in the zone. The active key should be used to sign the zone. 3. Key-Signing Keys 3.1. Key Timeline There are three significant differences between key-signing keys (KSKs) and ZSKs: Morris, et al. Expires August 21, 2009 [Page 11] Internet-Draft DNSSEC Key Timing Considerations February 2009 1. KSKs only sign the DNSKEY RRset. This means that, unlike ZSKs, it is feasible to use multiple KSKs to sign the zone without generating a excessive amount of signature data. 2. They have to involve the parent zone in the addition and removal of DS records. 3. KSKs may be configured as so-called "trust anchors" in validating resolvers. Whether or not a KSK is used as a trust anchor and how to transport the KSK to the validator in a secure way is outside the scope of this document. The first difference has led to the preferred method for handling KSK rollover [RFC4641] being that of double-signature: the DNSKEY RRset is signed by both the new key and the old key and the associated DS records for both published in the parent zone. After a suitable interval, the records for the old key are removed. This is the scheme described in the timeline below. The second difference means that timings are not wholly within the control of the zone manager, in that the time take to publish the DS records depends on the policies and procedures of the parent zone. A further ramification is that the independence of the parent DS and child DNSKEY records means that downstream validators might have inconsistent data, i.e. the DS record without the DNSKEY record or vice-versa. Although this is valid state according to [RFC4035], the information cannot be used for validation until the validator has both components. |1| |2| |3| |4| |5| |6| |7| |8| | | | | | | | | Key N | |<-Ip->|<-->|<-------Lk------->|<------>| | | | | | | | | Key N+1 | | | | |<-Ip->|<--->|<---Lk--- - - | | | | | | | | Tg Tp Tr Ta Tps Tt Tm ---- Time ----> Timeline for a KSK rollover. Figure 4 Event 1: key N is generated at time Tg and enters the generate state. As before, although there is no reason why the key cannot be Morris, et al. Expires August 21, 2009 [Page 12] Internet-Draft DNSSEC Key Timing Considerations February 2009 generated immediately prior to publication, some implementations may find its 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 also submitted to the parent zone for publication. This time is the publish time (Tp) and the KSK is said to be in the published state. Event 3: after some time (the publication interval, Ip), any validator that has copies of the DNSKEY and/or DS RRsets in its cache will have a copy of the data for key N. This point is the ready time and is given by: Tr = Tp + Ip In the case of the KSK, the publication interval depends on the publication interval of both the DNSKEY record and the DS record. These are independent of one another, so a suitable expression for Ip is: Ip = max(Ipc, Ipp) Ipc is the publication interval in the child zone and Ipp that of the parent. The child term comprises two parts - the time taken for the introduction of the DNSKEY record to be registered on the downstream slave servers (= Dpc, the child propagation delay) and the time taken for information about the DNSKEY RRset to expire from the validator cache, i.e. Ipc = max(TTLkeyc, Cc) + Dpc (TTLkeyc is the TTL for a DNSKEY record in the child zone and Cc the negative cache time in that zone. The max() function occurs to combine the separate expressions for the first and subsequent key in a zone, as described in event 3 in section Section 2.1.) The parent term is similar, but also includes the time taken for the DS record to be included in the parent zone after the request has been made. In other words: Ipp = Dr + max(TTLdsp, Cp) + Dpp (TTLdsp is the TTL for a DS record in the parent zone, Cp the negative cache time in that zone, Dpp the propagation delay. Dr is Morris, et al. Expires August 21, 2009 [Page 13] Internet-Draft DNSSEC Key Timing Considerations February 2009 the registration delay, which is the time taken between the submission of the DS record to the parent zone and its publication in the zone.) As the key has already been used to sign the DNSKEY RRset, the key is also active, in that all other KSKs could be withdrawn from the zone at this point and the zone would still be valid. However, while a predecessor key is active, it is convenient to regard the successor key as merely being ready. Event 4: at some later time, the predecessor key is withdrawn from the zone and, in the absence of any emergency keys, key N becomes the only KSK for the zone. The key is said to be active, and this time is the active time (Ta) Event 5: as with the ZSK, at some point we need to give thought to key replacement. The successor key must be introduced into the zone at a time such that when the current key is withdrawn, any validator that has key information (DNSKEY and/or DS records) in its cache will have data about the successor key. As before, this interval is the publication interval, Ip. Denoting the publication time of the successor key as Tps, we get: Tps <= Ta + Lk - Ip Event 6: the successor key (key N+1) enters the ready state. Event 7: at some time a decision will be made to retire the current key (key N). This will be when the current key has been active for its lifetime (Lk). At this point, the retire time, the successor key becomes active and the current key is said to be retired: Tt = Ta + Lk Event 8: at some later time, the DNSKEY record can be removed from the child zone and a request made to remove the DS record from the parent zone. This is the removal time, Tm and is given by: Tm >= Tt Note the differences to a ZSK. In the case of a ZSK, only one key at a time is used to sign the zone. Therefore, when the active ZSK is retired, there may be copies of signatures created using it in the caches of downstream validators. For this reason, a copy of the ZSK has to be kept in the zone until all cached signatures haver expired. With a KSK, both the active key and the successor key sign the DNSKEY Morris, et al. Expires August 21, 2009 [Page 14] Internet-Draft DNSSEC Key Timing Considerations February 2009 RRset. By the time the successor becomes active, any validator with the DNSKEY RRset in its cache has a copy of the successor key. Therefore as soon as the active key is retired, it can be removed from the zone - there is no retire interval or dead time. (Although for completeness, and in analogy with the ZSK, a dead time could be defined by Td = Tm.) 3.2. Emergency Key-Signing Keys In the same way that additional ZSKs are kept in a ready state in the zone to act as emergency keys, additional KSKs need to be available in the ready state for the same reason. The number of emergency keys kept available is a matter of key management policy, and the logic for the introduction of emergency keys into the zone is the same as that given in Section 2.2.1. 3.3. Key Rollover By definition, KSK rollovers have to involve the parent zone. If (as is the usual case) the parent zone is managed by a different entity then the timing of some of the steps in the KSK rollover operation may be subject to uncertainty. In the above analysis, this has been represented above by the DS registration delay (Dr); in practice, confirmation needs to be sought that the step has successfully completed. It is important to note however, that this does not preclude the development of key rollover logic similar to that described in Section 2.3.3 for the ZSKs. 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 waiting for the parent to respond, in addition to any interval 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. 3.4. Key Rollover Logic 3.4.1. Actual and Estimated Times Time stamps for KSK rollovers exhibit the same behaviour as for ZSK rollovers in that all times are estimates until after the event to which they refer has occurred. Morris, et al. Expires August 21, 2009 [Page 15] Internet-Draft DNSSEC Key Timing Considerations February 2009 3.4.2. Practical Timing Considerations For reasons given in section Section 2.3.2, it is prudent to include a safety margin in the initial publication interval used in any practical implementation of KSK timing, i.e. in the equations above replace Ip by Ip' where: Ip' = Ip + Sp As before, Sp is the publication safety interval, with a minimum value of the order of seconds, but a realistic value of the order of TTLsig. 3.4.3. KSK Management Procedure The following section describes the procedure for maintaining KSKs in a zone. It handles key rollover - both scheduled and emergency - as well as flagging which keys should be published in preparation for use in signing the zone. The procedure is largely similar to that used for ZSKs. As before, it is assumed that data about keys is held in some key management store, that the procedure is run on a regular basis and that "now()" is the time at which the procedure is run. Also defined is Nke as the number of emergency KSKs required to be able to immediately roll at any time for emergency reasons. A likely value is: Nke = 1 1. For all keys in the data store, calculate the estimated time of entering the next stage using the relationships described above. 2. If this procedure is being run as part of an emergency rollover, set the estimated retirement time for the active key as now(). (In this way, an emergency key rollover requires no special processing: it is merely the early retirement of the active key.) 3. For each published key, if now() >= Tr, mark the key as ready. 4. If now() is within (Ip + Ir) of the estimated retire time of the active key (where Ir is the interval between runs of the procedure) AND the number of keys in the publish and ready states combined is less than (1 + Nke), move a number of keys equal to the difference between these two values from the generate state into the publish state. (This step ensures that when the active key is retired, there are keys available to take over from it.) Morris, et al. Expires August 21, 2009 [Page 16] Internet-Draft DNSSEC Key Timing Considerations February 2009 The term Ir appears here because to avoid a policy violation (i.e. a delay in retiring the active key) this action must occur at least Ip before the estimated retire time of the key. As the procedure is run at intervals, the only way to guarantee this is to add a margin equal to the run interval. 5. If now() is earlier than the retire time of the current key, exit the procedure. (Note "earlier"; if an emergency rollover is taking place, the retirement time of the active key will be equal to now() due to the processing of step 2.) 6. Check whether there are keys in the ready state. If not, the currently active key cannot be retired and the procedure will have to wait until one or more keys become ready. In this case, exit the procedure. 7. Check that the DS record of the successor key is available from the parent zone. (The check may be made in a variety of ways, including querying one of or all of the parent nameservers, or just querying the server furthest down the chain of parent nameservers.) If the record is not available, exit the procedure. The key that will replace the active key is in the ready state. However, the entry to the ready state is based on the assumption that the DS record has been published after a time Dr. But that is only an assumption, and relies on the behaviour of the parent zone operator. To be safe, a check is made that the DS record has propagated through the parent's server network. If it hasn't, there may have been some breakdown in communication with the parent zone. 8. Mark the active key as retired. 9. Mark the successor key as active. After this procedure, all keys in the publish, ready and active states should be published in the zone. Retired keys may be removed from the zone when convenient. 4. Running the Key Management Procedures The preceding sections outlined procedures to be used to manage KSKs and ZSKs. One way to use these procedures is to run them only when a significant event occurs. In other words, when a procedure completes, calculate the time at which the next event will occur and run it again at that time. Morris, et al. Expires August 21, 2009 [Page 17] Internet-Draft DNSSEC Key Timing Considerations February 2009 In practice though (and what has been assumed in the management procedures outlined above), it will be easier to run them on a regular basis. This has two implications: 1. Depending on the frequency of running the procedure, in many cases the result will be a no-op; the set of keys to be published in the zone will be unchanged from the last time it is run. 2. Policy will not be enforced exactly, e.g. the a key may remain active longer that the key lifetime because the procedure is not run until some time after the retire time of the active key is reached. Neither of these objections is fatal. In the first case, it will be easy to detect that a key set is unchanged and so prevent a needless update. The latter case is dealt with by reducing the run interval to the point at which the maximum delay in making a transition between the states of keys is acceptable. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations This document does not introduce any new security issues beyond those already discussed in [RFC4033], [RFC4034] and [RFC4035]. 7. Acknowledgements The authors gratefully acknowledge help and contributions from Roy Arends and Wouter Wijngaards. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Morris, et al. Expires August 21, 2009 [Page 18] Internet-Draft DNSSEC Key Timing Considerations February 2009 [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. [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. Appendix A. List of Symbols The following symbols have been used in the text: C Negative cache time. Cc Negative cache time in the child zone. Cp Negative cache time in the parent zone. Dp Propagation delay. The amount of time for a change made at a master nameserver to propagate to all the slave nameservers. Dpc Propagation delay in the child zone. Dpp Propagation delay in the parent zone. Dr Registration delay, the time between submission of a DS record to the parent zone and its publication in the zone. Ip 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. Ip' Publication interval taking into account a safety margin. Ipc Publication interval for the child zone. Ipp Publication interval for the parent zone. Ir Run interval. The time between successive runs of the key rollover procedure. Morris, et al. Expires August 21, 2009 [Page 19] Internet-Draft DNSSEC Key Timing Considerations February 2009 It 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 validator caches. It' Retire interval taking into account a safety margin. Lk 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. Lz 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. Nke Number of emergency KSKs in a zone. Nze Number of emergency ZSKs in a zone. SOAmin The value of the "minimum" parameter in the zone's SOA record. Sp Publish safety margin. An interval of time used to guarantee that a key is truly in the ready state. St Retire safety margin. An interval of time used to guarantee that a key is truly in the dead state. Ta Active time of the key. For a ZSK, the time that they key is first used to sign the zone. For a KSK, the time at which this key is regarded as being the principal KSK for the zone. Td Dead time of a key. Applicable only to ZSKs, this is the time at which any record signatures held in validator caches are guaranteed to be created with the successor key. Tg Generate time of a key. The time that a key is created. Tm Removal time of a key. The time at which a key is removed from the zone. Tp Publish time of a key. The time that a key appears in a zone for the first time. Morris, et al. Expires August 21, 2009 [Page 20] Internet-Draft DNSSEC Key Timing Considerations February 2009 Tps Publish time of the successor key. Tr Ready time of a key. The time at which it can be guaranteed that a validators that have key information from this zone cached have a copy of this key in their cache. (In the case of KSKs, should the validators also have DS information from the parent zone cached, the cache must include information about the DS record corresponding to the key.) Tt Retire time of a key. The time at which a successor key starts being used to sign the zone. TTLdsp 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. TTLsig Time to live of a RRSIG record. Authors' Addresses Stephen Morris Nominet Minerva House, Edmund Halley Road Oxford, OX4 4DQ UK Phone: +44 1865 332211 Email: stephen@nominet.org.uk Johan Ihren Autonomica Bellmansgatan 30 Stockholm, SE-118 47 Sweden Phone: +46 8615 8573 Email: johani@autonomica.se Morris, et al. Expires August 21, 2009 [Page 21] Internet-Draft DNSSEC Key Timing Considerations February 2009 John Dickinson 6 Nelson Close Wallingford, OX10 0LG UK Phone: Email: jad@jadickinson.co.uk Morris, et al. Expires August 21, 2009 [Page 22]