[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [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: April 18, 2010                                       Autonomica
                                                            J. Dickinson
                                                        October 15, 2009


                    DNSSEC Key Timing Considerations
              draft-morris-dnsop-dnssec-key-timing-01.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 April 18, 2010.

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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes the issues surrounding the timing of events



Morris, et al.           Expires April 18, 2010                 [Page 1]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   in the rolling of a key in a DNSSEC-secured zone.  It presents
   timlines for the key rollover and explicitly identifies the
   relationships between the various parameters affecting the process.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Types of Key Rollover  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Pre-Publication Method . . . . . . . . . . . . . . . . . .  4
     2.2.  Double-Signature Method  . . . . . . . . . . . . . . . . .  5
     2.3.  Comparison of Rollover Methods . . . . . . . . . . . . . .  5
     2.4.  Timing Considerations  . . . . . . . . . . . . . . . . . .  5
   3.  Zone-Signing Keys  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Key Timeline . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Key States . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Stand-By Zone-Signing Keys . . . . . . . . . . . . . . . . 10
       3.3.1.  Stand-By Key Scheduling  . . . . . . . . . . . . . . . 10
       3.3.2.  Number of Stand-By Keys  . . . . . . . . . . . . . . . 11
   4.  Key-Signing Keys . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  Parent Zone Considerations . . . . . . . . . . . . . . . . 13
     4.3.  Rollover Strategies  . . . . . . . . . . . . . . . . . . . 14
     4.4.  Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 15
     4.5.  Key States . . . . . . . . . . . . . . . . . . . . . . . . 19
     4.6.  Stand-By Key-Signing Keys  . . . . . . . . . . . . . . . . 19
   5.  Algorithm Considerations . . . . . . . . . . . . . . . . . . . 19
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 20
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 21
   Appendix A.  List of Symbols . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25














Morris, et al.           Expires April 18, 2010                 [Page 2]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


1.  Introduction

   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 reasons.  In order to implement
   a key rollover, the keys need to 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 systems 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 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.

   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.

   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
   [RFC5011].



Morris, et al.           Expires April 18, 2010                 [Page 3]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   A large number of symbols are used in this document to identify
   times, intervals, etc.  All are listed in Appendix A.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Types of Key Rollover

   As noted in the introduction, client resolvers may cache both key and
   signature RRsets.  This means that when validating a signature record
   (or passing both RRsets to a client who has issued a query with the
   CD bit set), an RRSIG just read from an authoritative server may be
   paired with a cached DNSKEY or vice-versa.  For the validation to be
   successful, the DNSKEY and RRSIG must be consistent.

   Key rollover - the replacement of the key use to sign the zone with
   another - involves changing the contents of the DNSKEY RRset and re-
   signing the zone (so changing the RRSIG records).  In order for a RR
   to be validated, at least one RRSIG in the associated signature RRset
   must be able to be validated by one of the keys in the DNSKEY RRset.
   To ensure uninterrupted security, the aim must be to ensure that this
   condition is true at all stages during the rollover process.

   Two ways to achieve this goal are the pre-publication method and the
   double signature method.

2.1.  Pre-Publication Method

   In pre-publication, 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 resolvers contain both keys.  At that point,
   the zone can be signed with the 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
   will have a copy of the DNSKEY RRset 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, the old key can be
   removed from the DNSKEY RRset because there will be no signatures
   anywhere created using it.



Morris, et al.           Expires April 18, 2010                 [Page 4]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


2.2.  Double-Signature Method

   Double-signature, as the name implies, 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 and RRSIG RRsets allows
   at least one signature to be validated.

   Once the signing process is complete and enough time has elapsed to
   allow all old DNSKEY and RRSIG RRsets to expire from caches, the old
   key and signatures can be removed from the zone.  As before, during
   this period any combination of DNSKEY and RRSIG RRsets will allow
   validation of at least one signature.

2.3.  Comparison of Rollover Methods

   Of the two methods, double-signature is the simplest conceptually -
   introduce the new key and new signatures, then (roughly) 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.  This
   affects both the overall size of the zone and the size of the
   responses.

   Pre-publication is more complex - introduce the new key, one TTL
   later sign the records, and one TTL after that remove the old key.
   However, the amount of DNSSEC data is kept to a minimum, hence
   reducing the impact on performance.

2.4.  Timing Considerations

   The rest of this paper describes the timing considerations related to
   the rolling of zone-signing keys (ZSKs) and key-signing keys (KSKs).
   Owing to the increase in the amount of DNSSEC data in the double-
   signature method, the pre-publication approach is preferred for
   rollover of ZSKs.  However, in the case of KSK rollovers, the size
   increase is negligible and hence the complexity of pre-publication is
   not justified.

   While this combination is the most common choice of rollover logic,
   there is nothing to preclude other combinations should the situation
   demand it.  The rest of this document describes ZSK and KSK rollover
   timelines for the common case.







Morris, et al.           Expires April 18, 2010                 [Page 5]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


3.  Zone-Signing Keys

3.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   |    |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->|
             |    |        |     |     |        |   |        |     |
     Key N+1 |    |        |     |     |<-Ipub->|<->|<---Lzsk-- - -
             |    |        |     |     |        |   |        |     |
            Tgen Tpub     Trdy  Tact  TpubS        Tret     Tdea  Trem

                             ---- Time ---->


                  Figure 1: Timeline for a 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 key
   N 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.

   The interval is the publication interval (Ipub) and, for the second
   or subsequent keys in the zone, is given by:




Morris, et al.           Expires April 18, 2010                 [Page 6]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


             Ipub = Dprp + TTLkey

   Here, Dprp is the propagation delay - the time take 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 validators, 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
   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 can 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 activation time (Tact) 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 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 lives for slightly more or less than



Morris, et al.           Expires April 18, 2010                 [Page 7]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   Lzsk.

   Event 6: while the current ZSK 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
   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 validator.  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.)




Morris, et al.           Expires April 18, 2010                 [Page 8]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   The time at which all RRSIG records created with this key expire from
   resolver caches is the dead time (Tdea), given by:

             Tdea = Tret + Iret

   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:

             Trem >= Tdea

   ...and the key is said to be in the removed state.

3.2.  Key States

   An alternative way of considering the key timeline is to regard the
   key as moving through a set of states, the state transitions being
   determined by time.  The state transition diagram is linear and is
   shown in Figure 2:



                  +-----------+      +-----------+      +-----------+
       Start ---->| Generated |----->| Published |----->|   Ready   |
             Tgen +-----------+ Tpub +-----------+ Trdy +-----------+
                                                              |
                                     +-----------+            |
                        +------------|   Active  |<-----------+
                        |   Tret     +-----------+    Tact
                        V
                  +-----------+      +-----------+      +-----------+
                  |  Retired  |----->|    Dead   |----->|  Removed  |
                  +-----------+ Tdea +-----------+ Trem +-----------+


                       Figure 2: ZSK State Diagram.

   The states are:

   Generated   The key has been created.

   Published   The DNSKEY record is published in the zone, but resolvers
               may have earlier versions of the DNSKEY RRset in their
               cache.







Morris, et al.           Expires April 18, 2010                 [Page 9]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   Ready       The key has been published for long enough to guarantee
               that all cached versions of the zone's DNSKEY RRset
               contain this key.

   Active      The key is in the zone and is being used to sign RRsets.

   Retired     The key is in the zone but is no longer being used to
               sign RRsets.  However, there may still be RRSIG records
               in caches that were created with this key.

   Dead        The key is published in the zone but there are no RRSIGs
               in existence created with this key.

   Removed     The key has been removed from the zone.

3.3.  Stand-By Zone-Signing Keys

   Although ZSKs will usually be rolled according to some regular
   schedule, there may be occasions when an emergency ZSK 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 at least one stand-by ZSK in
   this state at all times will minimise delay.

3.3.1.  Stand-By Key Scheduling

   One way to achieve this is to regard successor keys as stand-by keys
   for emergency rollovers and to introduce them in the zone as early as
   possible.  A modification of Figure 1 illustrates this:



                    |1|      |2|      |3|             |4|
                     |        |        |               |
      Key N  - - - -----Lzsk---------->|               |
                     |        |        |               |
      Key N+1  - --------------------->|<----Lzsk----->|
                     |        |        |               |
      Key N+2        |<-Ipub->|<---------------------->|<--Lzsk-- - -
                     |        |        |               |

                              ---- Time ---->


           Figure 3: Timeline showing stand-by key replacement.

   In this figure, it is assumed that key N is initially in the active



Morris, et al.           Expires April 18, 2010                [Page 10]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   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 stand-by key for an
   emergency re-signing until the time comes to use it to sign the zone.

   Event 1: At least Ipub 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
   Section 3.1, events 7 - 9).  Key N+2 is now regarded as the stand-by
   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 stand-by keys for emergency
   use.  An equally valid alternative would be to have a permanent
   stand-by key.  In this scheme, a key is published in the zone but,
   unless it needs to be used in an emergency, is never used to sign it.
   Instead, active keys are replaced by their successors as shown in
   Figure 1.

3.3.2.  Number of Stand-By Keys

   An emergency key rollover could be required at any time.  Referring
   back to Figure 3, 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 stand-by
   key when the current stand-by key becomes active.  In the worst case
   though, it may be required that the system run without an stand-by
   key for a while.  For example, if a key rollover was required between
   events 3 and 4 in Figure 3, the timeline would look like:

















Morris, et al.           Expires April 18, 2010                [Page 11]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


                                    |3a|     |3b|
                                     |        |
               Key N+1  - ---Lzsk--->|        |
                                     |        |
               Key N+2  - ---------->|<----------Lzsk---- - -
                                     |        |
               Key N+3               |<-Ipub->|<-------- - -
                                     |        |

                                  ---- Time ---->


            Figure 4: Timeline showing emergency key rollover.

   (The interval shown above lies between events 3 and 4 in Figure 3,
   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 stand-by key (N+2) is in the ready state.  It is well
   before the active key's retire time, so there are only these two 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 stand-by 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 stand-by key (N+3) becomes ready.  Of course, this can
   be mitigated by having a number of stand-by 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.


4.  Key-Signing Keys

4.1.  Introduction

   There are three significant differences between key-signing keys
   (KSKs) and ZSKs:

   1.  In the ZSK case the issue for the validator 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 and the



Morris, et al.           Expires April 18, 2010                [Page 12]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


       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 a DS record in
       the parent (which is itsef trusted), or the KSK being explicitly
       configured as a trust anchor for the validator.  Hence the
       additional two differences:

   2.  A KSK rollover algorithm may need 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.

   These differences have the following implications for KSK rollovers:

   1.  The rollover logic must ensure that validators are able to
       validate the DNSKEY RRset throughout the rollover process -
       either through updates to the chain of trust from the parent zone
       or through updates to the trust anchor configuration.

   2.  Timings are not wholly within the control of the zone manager, in
       that the time taken to publish the DS records depends on the
       policies and procedures of the parent zone.  A consequence of
       this is that the interdependence of the parent DS and child
       DNSKEY records means that when a new key is introduced, for a
       period 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.

   3.  Securely removing such KSKs from the zone requires a mechanism
       for communicating this information to any validators that may
       have the KSK configured as a trust-anchor.  The typical method
       would be by publishing the revoked key as described in [RFC5011].

   There are some differences in the sequence of events between the
   cases of a zone where a KSK is authenticated via a DS record in the
   parent zone and one where it is authenticated by a trust anchor
   configured into a validator.  These will be highlighted as
   appropriate.

4.2.  Parent Zone Considerations

   If (as is the usual case) the parent and child zones are managed by
   different entities, the timing of some of the steps in the KSK
   rollover operation may be subject to uncertainty.



Morris, et al.           Expires April 18, 2010                [Page 13]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   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.

4.3.  Rollover Strategies

   When the parent zone is secured, there are several different ways to
   roll a KSK whilst ensuring that the zones do not go insecure or bogus
   in the process:

   o  Double KSK: 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
      DNSKEY 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 validator caches, the old key is removed from
      the DNSKEY RRset.

   o  Double DS: the new DS record is published.  After waiting for this
      change to propagate into the caches of all validators, 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 validator caches, the
      old DNSKEY and DS record are removed.

   In essence, "Double KSK" means that the new KSK is introduced first,
   and then the new DS (for this KSK).  With "Double DS" it is the other
   way around.  Finally, Double RRset does both updates more or less in
   parallel.

   Of the three methods, the double RRset method is preferred because:

   o  It allows the rollover to be done in the shortest time.

   o  It can support policies that require a period of running with old
      and new KSKs simultaneously.




Morris, et al.           Expires April 18, 2010                [Page 14]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


4.4.  Key Timeline

   The timeline for the key rollover is shown below:



             |1|  |2|      |3|  |4|   |5|      |6|   |7|      |8|
              |    |        |    |     |        |     |        |
      Key N   |    |<-Ipub->|<-->|<-------Lksk------->|<-Iret->|
              |    |        |    |     |        |     |        |
      Key N+1 |    |        |    |     |<-Ipub->|<--->|<---Lksk-- - -
              |    |        |    |     |        |     |        |
            Tgen  Tpub    Trdy  Tact TpubS    TrdyS  Tret    Trem

                              ---- Time ---->


                  Figure 5: Timeline for a KSK rollover.

   Event 1: key N is generated at time Tgen and enters the generate
   state.  As before, although there is no reason why the key cannot be
   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 this time the corresponding
   DS record is made available.  If the parent zone is secure, this
   means submitting the DS record to the parent zone for publication; if
   not, it is distributed by some mechanism to allow validators to
   configure it as a trust anchor.  This time is the publish time (Tpub)
   and the KSK is said to be in the published state.

   Event 3: after some time (the publication interval, Ipub), 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:

             Trdy = Tpub + Ipub

   Regarding the associated DS record, there are now two cases to
   consider, where the parent is signed and where the parent is not
   signed:

   Event 3 (parent signed): 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, so a suitable
   expression for Ipub is:



Morris, et al.           Expires April 18, 2010                [Page 15]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


             Ipub = max(IpubC, IpubP)

   IpubC is the publication interval in the child zone and IpubP 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
   secondary servers (= DprpC, the child propagation delay) and the time
   taken for information about the DNSKEY RRset to expire from the
   validator cache, i.e.

             IpubC = DprpC + TTLkeyC

   (TTLkeyC is the TTL for a DNSKEY record in the child zone.)

   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:

             IpubP = Dreg + DprpP + TTLds

   Dreg is 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.  DprpP the propagation delay in the parent zone and TTLds
   the TTL for a DS record.

   Throughout the introduction of the two RRs, the zone can be validated
   by by the existing KSK and DS record.  However, there are special
   considerations regarding the first KSK in a zone, and these are
   discussed below.

   Event 3 (parent not signed): if the parent is not signed then there
   is no parent publication interval (theoretically the DS record could
   be configured in a validator immediately it is made available), in
   which case the minimumn value of the publication interval is given
   by:

             Ipub = IpubC

   Event 3 (common): In both cases, if the management policy is to
   support [RFC5011], there is also the additional condition that the
   new key needs to be published for at least as long as the RFC5011 add
   hold-down time, defined in that document as "30 days or the
   expiration time of the original TTL of the first trust point DNSKEY
   RRSet that contained the new key, whichever is greater".

   This can be expressed as the condition:




Morris, et al.           Expires April 18, 2010                [Page 16]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


             Ipub >= max(30 days, TTLkey)

   At Trdy, 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 (Tact).

   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, Ipub.  Denoting
   the publication time of the successor key as TpubS, we get:

             TpubS <= Tact + Lksk - Ipub

   ... where Lksk is the lifetime of the KSK.

   Event 6: the successor key (key N+1) enters the ready state.  This
   occurs at TrdyS, given by:

             TrdyS = TpubS + Ipub

   Event 7: at some time after that 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 (Lksk).  At this point, the retire time, the
   successor key becomes active and the current key is said to be
   retired:

             Tret = Tact + Lksk

   (... with the obvious condition that Tret >= TrdyS.)

   If the management policy is to support [RFC5011], the retired key
   should now have the revoke bit set and be included in the DNSKEY
   RRset. the revoked key should also be used to sign it.

   Event 8: at some later time, the DNSKEY record can be removed from
   the child zone.  If there is a secure parent, a request can be made
   to remove the DS record from the parent zone.  This is the removal



Morris, et al.           Expires April 18, 2010                [Page 17]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   time, Trem and is given by:

             Trem = Tret + Iret

   where, as before, Iret is the retire interval.  This will be zero
   unless [RFC5011] is being followed, in which case Iret will be equal
   to the RFC5011 remove hold-down time value of 30 days.

   Notes:

   1.  In the case of a ZSK, as pre-publication is the method of choice,
       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 have expired.

       With a KSK - where double RRset is the method of choice - both
       the active key and the successor key sign the DNSKEY 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 (unless [RFC5011] is
       being followed) or dead time (although for completeness, and in
       analogy with the ZSK, a dead time could be defined by Tdea =
       Trem).

   2.  There is an additional consideration when introducing a KSK into
       a zone for the first time, and that is that no validator can be
       in a position where it can access the trust anchor before the KSK
       appears in the zone.  To do so will cause the validator to
       declare the zone to be bogus.

   The second point 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 validator 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 validators 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





Morris, et al.           Expires April 18, 2010                [Page 18]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


             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.  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 one to allow for the effect
   of negative caching.

4.5.  Key States

   The key states for a KSK during the rollover are identical to those
   in Figure 2.

4.6.  Stand-By 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 stand-by keys
   kept available is a matter of key management policy, and the logic
   for the introduction of stand-by keys into the zone follows the same
   reasoning as that given in Section 3.3 on the introduction of
   stand-by ZSKs.


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 changes - there is no
   relationship between the keys of different algorithms.  This means
   that they can be rolled independently of one another.  (Indeed, the
   keys for each algorithm could, if desired, have different TTLs.)  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.





Morris, et al.           Expires April 18, 2010                [Page 19]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


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 and remove hold-down times.  It should be emphasised 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 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
   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-01
      * Use latest boilerplate for IPR text.
      * List different ways to roll a KSK (acknowledgements to Mark
      Andrews).
      * Restucture to concentrate on key timing, not management
      procedures.



Morris, et al.           Expires April 18, 2010                [Page 20]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


      * Change symbol notation (Diane Davidowicz and others).
      * Added key state transition diagram (Diane Davidowicz).
      * Corrected spelling, formatting, grammatical and style errors
      (Diane Davidowicz, Alfred Hones 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 Hones).
      * 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.  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.

   [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.


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:



Morris, et al.           Expires April 18, 2010                [Page 21]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


             <TYPE><id><INST>

   where:

   <TYPE> is an upper-case character indicating what type the symbol is.
   Defined types are:

   D         delay: interval that is a feature of the process

   L         lifetime: calculated interval set by the zone manager

   I         interval between two events

   L         lifetime: interval set by the zone manager

   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 terms.

   <id> is lower-case and defines what object or event the variable is
   related to, e.g.

   act       active

   ngc       negative cache

   pub       publication

   Finally, <INST> is a capital letter that distinguishes between the
   same variable applying to different instances of an object and is one
   of:

   C         child







Morris, et al.           Expires April 18, 2010                [Page 22]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   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.

   DprpP     Propagation delay in the parent zone.

   Dreg      Registration delay.  As a parent zone are often managed by
             a different organisation to the one under consideration,
             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.

   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.

   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 validator caches.

   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.

   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.




Morris, et al.           Expires April 18, 2010                [Page 23]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   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 validator.)

   SOAmin    Value of the "minimum" field from an SOA record.

   Tact      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.

   Tdea      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.

   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 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.)

   TrdyS     Ready time of a successor key.

   TTLds     Time to live of a DS record (in the parent zone).

   TTLkey    Time to live of a DNSKEY record.






Morris, et al.           Expires April 18, 2010                [Page 24]


Internet-Draft      DNSSEC Key Timing Considerations        October 2009


   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 an RRSIG record.

   Ttsa      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
   Nominet
   Minerva House, Edmund Halley Road
   Oxford,   OX4 4DQ
   UK

   Phone: +44 1865 332211
   Email: stephen@nominet.org.uk


   Johan Ihren
   Autonomica
   Franzengatan 5
   Stockholm,   SE-112 51
   Sweden

   Phone: +46 8615 8573
   Email: johani@autonomica.se


   John Dickinson
   Stables 4 Suite 10, Howbery Park
   Wallingford,   OX10 8BA
   UK

   Phone:
   Email: jad@jadickinson.co.uk











Morris, et al.           Expires April 18, 2010                [Page 25]


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