[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-dnsop-dnssec-key-timing

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/