tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6781

 
 
 

DNSSEC Operational Practices, Version 2

Part 2 of 4, p. 18 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
4.  Signature Generation, Key Rollover, and Related Policies

4.1.  Key Rollovers

   Regardless of whether a zone uses periodic key rollovers or only
   rolls keys in case of an irregular event, key rollovers are a fact of
   life when using DNSSEC.  Zone administrators who are in the process
   of rolling their keys have to take into account the fact that data
   published in previous versions of their zone still lives in caches.
   When deploying DNSSEC, this becomes an important consideration;
   ignoring data that may be in caches may lead to loss of service for
   clients.

   The most pressing example of this occurs when zone material signed
   with an old key is being validated by a resolver that does not have
   the old zone key cached.  If the old key is no longer present in the
   current zone, this validation fails, marking the data Bogus.
   Alternatively, an attempt could be made to validate data that is
   signed with a new key against an old key that lives in a local cache,
   also resulting in data being marked Bogus.

   The typographic conventions used in the diagrams below are explained
   in Appendix B.

4.1.1.  Zone Signing Key Rollovers

   If the choice for splitting ZSKs and KSKs has been made, then those
   two types of keys can be rolled separately, and ZSKs can be rolled
   without taking into account DS records from the parent or the
   configuration of such a key as the trust anchor.

   For "Zone Signing Key rollovers", there are two ways to make sure
   that during the rollover data still cached can be verified with the
   new key sets or newly generated signatures can be verified with the
   keys still in caches.  One scheme, described in Section 4.1.1.1, uses

Top      Up      ToC       Page 19 
   key pre-publication; the other uses double signatures, as described
   in Section 4.1.1.2.  The pros and cons are described in
   Section 4.1.1.3.

4.1.1.1.  Pre-Publish Zone Signing Key Rollover

   This section shows how to perform a ZSK rollover without the need to
   sign all the data in a zone twice -- the "Pre-Publish key rollover".
   This method has advantages in the case of a key compromise.  If the
   old key is compromised, the new key has already been distributed in
   the DNS.  The zone administrator is then able to quickly switch to
   the new key and remove the compromised key from the zone.  Another
   major advantage is that the zone size does not double, as is the case
   with the Double-Signature ZSK rollover.

   Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves
   four stages as follows:

    ------------------------------------------------------------
     initial            new DNSKEY          new RRSIGs
    ------------------------------------------------------------
     SOA_0              SOA_1               SOA_2
     RRSIG_Z_10(SOA)    RRSIG_Z_10(SOA)     RRSIG_Z_11(SOA)

     DNSKEY_K_1         DNSKEY_K_1          DNSKEY_K_1
     DNSKEY_Z_10        DNSKEY_Z_10         DNSKEY_Z_10
                        DNSKEY_Z_11         DNSKEY_Z_11
     RRSIG_K_1(DNSKEY)  RRSIG_K_1(DNSKEY)   RRSIG_K_1(DNSKEY)
    ------------------------------------------------------------

    ------------------------------------------------------------
     DNSKEY removal
    ------------------------------------------------------------
     SOA_3
     RRSIG_Z_11(SOA)

     DNSKEY_K_1
     DNSKEY_Z_11

     RRSIG_K_1(DNSKEY)
    ------------------------------------------------------------

                    Figure 1: Pre-Publish Key Rollover

Top      Up      ToC       Page 20 
   initial:  Initial version of the zone: DNSKEY_K_1 is the Key Signing
      Key.  DNSKEY_Z_10 is used to sign all the data of the zone, i.e.,
      it is the Zone Signing Key.

   new DNSKEY:  DNSKEY_Z_11 is introduced into the key set (note that no
      signatures are generated with this key yet, but this does not
      secure against brute force attacks on its public key).  The
      minimum duration of this pre-roll phase is the time it takes for
      the data to propagate to the authoritative servers, plus the TTL
      value of the key set.

   new RRSIGs:  At the "new RRSIGs" stage, DNSKEY_Z_11 is used to sign
      the data in the zone exclusively (i.e., all the signatures from
      DNSKEY_Z_10 are removed from the zone).  DNSKEY_Z_10 remains
      published in the key set.  This way, data that was loaded into
      caches from the zone in the "new DNSKEY" step can still be
      verified with key sets fetched from this version of the zone.  The
      minimum time that the key set including DNSKEY_Z_10 is to be
      published is the time that it takes for zone data from the
      previous version of the zone to expire from old caches, i.e., the
      time it takes for this zone to propagate to all authoritative
      servers, plus the Maximum Zone TTL value of any of the data in the
      previous version of the zone.

   DNSKEY removal:  DNSKEY_Z_10 is removed from the zone.  The key set,
      now only containing DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with
      DNSKEY_K_1.

Top      Up      ToC       Page 21 
   The above scheme can be simplified by always publishing the "future"
   key immediately after the rollover.  The scheme would look as
   follows (we show two rollovers); the future key is introduced in "new
   DNSKEY" as DNSKEY_Z_12 and again a newer one, numbered 13, in "new
   DNSKEY (II)":

       initial             new RRSIGs          new DNSKEY
      -----------------------------------------------------------------
       SOA_0               SOA_1               SOA_2
       RRSIG_Z_10(SOA)     RRSIG_Z_11(SOA)     RRSIG_Z_11(SOA)

       DNSKEY_K_1          DNSKEY_K_1          DNSKEY_K_1
       DNSKEY_Z_10         DNSKEY_Z_10         DNSKEY_Z_11
       DNSKEY_Z_11         DNSKEY_Z_11         DNSKEY_Z_12
       RRSIG_K_1(DNSKEY)   RRSIG_K_1(DNSKEY)   RRSIG_K_1(DNSKEY)
       ----------------------------------------------------------------

       ----------------------------------------------------------------
       new RRSIGs (II)     new DNSKEY (II)
       ----------------------------------------------------------------
       SOA_3               SOA_4
       RRSIG_Z_12(SOA)     RRSIG_Z_12(SOA)

       DNSKEY_K_1          DNSKEY_K_1
       DNSKEY_Z_11         DNSKEY_Z_12
       DNSKEY_Z_12         DNSKEY_Z_13
       RRSIG_K_1(DNSKEY)   RRSIG_K_1(DNSKEY)
       ----------------------------------------------------------------

             Figure 2: Pre-Publish Zone Signing Key Rollover,
                           Showing Two Rollovers

   Note that the key introduced in the "new DNSKEY" phase is not used
   for production yet; the private key can thus be stored in a
   physically secure manner and does not need to be 'fetched' every time
   a zone needs to be signed.

4.1.1.2.  Double-Signature Zone Signing Key Rollover

   This section shows how to perform a ZSK rollover using the double
   zone data signature scheme, aptly named "Double-Signature rollover".

   During the "new DNSKEY" stage, the new version of the zone file will
   need to propagate to all authoritative servers and the data that
   exists in (distant) caches will need to expire, requiring at least
   the propagation delay plus the Maximum Zone TTL of previous versions
   of the zone.

Top      Up      ToC       Page 22 
   Double-Signature ZSK rollover involves three stages as follows:

      ----------------------------------------------------------------
      initial             new DNSKEY         DNSKEY removal
      ----------------------------------------------------------------
      SOA_0               SOA_1              SOA_2
      RRSIG_Z_10(SOA)     RRSIG_Z_10(SOA)
                          RRSIG_Z_11(SOA)    RRSIG_Z_11(SOA)
      DNSKEY_K_1          DNSKEY_K_1         DNSKEY_K_1
      DNSKEY_Z_10         DNSKEY_Z_10
                          DNSKEY_Z_11        DNSKEY_Z_11
      RRSIG_K_1(DNSKEY)   RRSIG_K_1(DNSKEY)  RRSIG_K_1(DNSKEY)
      ----------------------------------------------------------------

           Figure 3: Double-Signature Zone Signing Key Rollover

   initial:  Initial version of the zone: DNSKEY_K_1 is the Key Signing
      Key.  DNSKEY_Z_10 is used to sign all the data of the zone, i.e.,
      it is the Zone Signing Key.

   new DNSKEY:  At the "new DNSKEY" stage, DNSKEY_Z_11 is introduced
      into the key set and all the data in the zone is signed with
      DNSKEY_Z_10 and DNSKEY_Z_11.  The rollover period will need to
      continue until all data from version 0 (i.e., the version of the
      zone data containing SOA_0) of the zone has been replaced in all
      secondary servers and then has expired from remote caches.  This
      will take at least the propagation delay plus the Maximum Zone TTL
      of version 0 of the zone.

   DNSKEY removal:  DNSKEY_Z_10 is removed from the zone, as are all
      signatures created with it.  The key set, now only containing
      DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11.

   At every instance, RRSIGs from the previous version of the zone can
   be verified with the DNSKEY RRset from the current version and vice
   versa.  The duration of the "new DNSKEY" phase and the period between
   rollovers should be at least the propagation delay to secondary
   servers plus the Maximum Zone TTL of the previous version of the
   zone.

   Note that in this example we assumed for simplicity that the zone was
   not modified during the rollover.  In fact, new data can be
   introduced at any time during this period, as long as it is signed
   with both keys.

Top      Up      ToC       Page 23 
4.1.1.3.  Pros and Cons of the Schemes

   Pre-Publish key rollover:  This rollover does not involve signing the
      zone data twice.  Instead, before the actual rollover, the new key
      is published in the key set and thus is available for
      cryptanalysis attacks.  A small disadvantage is that this process
      requires four stages.  Also, the Pre-Publish scheme involves more
      parental work when used for KSK rollovers, as explained in
      Section 4.1.2.

   Double-Signature ZSK rollover:  The drawback of this approach is that
      during the rollover the number of signatures in your zone doubles;
      this may be prohibitive if you have very big zones.  An advantage
      is that it only requires three stages.

4.1.2.  Key Signing Key Rollovers

   For the rollover of a Key Signing Key, the same considerations as for
   the rollover of a Zone Signing Key apply.  However, we can use a
   Double-Signature scheme to guarantee that old data (only the apex key
   set) in caches can be verified with a new key set and vice versa.
   Since only the key set is signed with a KSK, zone size considerations
   do not apply.

   Note that KSK rollovers and ZSK rollovers are different in the sense
   that a KSK rollover requires interaction with the parent (and
   possibly replacing trust anchors) and the ensuing delay while waiting
   for it.

Top      Up      ToC       Page 24 
   ---------------------------------------------------------------------
    initial            new DNSKEY        DS change    DNSKEY removal
   ---------------------------------------------------------------------
   Parent:
    SOA_0 -----------------------------> SOA_1 ------------------------>
    RRSIG_par(SOA) --------------------> RRSIG_par(SOA) --------------->
    DS_K_1 ----------------------------> DS_K_2 ----------------------->
    RRSIG_par(DS) ---------------------> RRSIG_par(DS) ---------------->

   Child:
    SOA_0              SOA_1 -----------------------> SOA_2
    RRSIG_Z_10(SOA)    RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA)

    DNSKEY_K_1         DNSKEY_K_1 ------------------>
                       DNSKEY_K_2 ------------------> DNSKEY_K_2
    DNSKEY_Z_10        DNSKEY_Z_10 -----------------> DNSKEY_Z_10
    RRSIG_K_1(DNSKEY)  RRSIG_K_1 (DNSKEY) ---------->
                       RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY)
   ---------------------------------------------------------------------

           Figure 4: Stages of Deployment for a Double-Signature
                         Key Signing Key Rollover

   initial:  Initial version of the zone.  The parental DS points to
      DNSKEY_K_1.  Before the rollover starts, the child will have to
      verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
      it is needed during the rollover, and we refer to the value as
      TTL_DS.

   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
      generates a second KSK, DNSKEY_K_2.  The key is provided to the
      parent, and the child will have to wait until a new DS RR has been
      generated that points to DNSKEY_K_2.  After that DS RR has been
      published on all servers authoritative for the parent's zone, the
      zone administrator has to wait at least TTL_DS to make sure that
      the old DS RR has expired from caches.

   DS change:  The parent replaces DS_K_1 with DS_K_2.

   DNSKEY removal:  DNSKEY_K_1 has been removed.

   The scenario above puts the responsibility for maintaining a valid
   chain of trust with the child.  It also is based on the premise that
   the parent only has one DS RR (per algorithm) per zone.  An
   alternative mechanism has been considered.  Using an established
   trust relationship, the interaction can be performed in-band, and the
   removal of the keys by the child can possibly be signaled by the
   parent.  In this mechanism, there are periods where there are two DS

Top      Up      ToC       Page 25 
   RRs at the parent.  This is known as a KSK Double-DS rollover and is
   shown in Figure 5.  This method has some drawbacks for KSKs.  We
   first describe the rollover scheme and then indicate these drawbacks.

   --------------------------------------------------------------------
     initial         new DS         new DNSKEY       DS removal
   --------------------------------------------------------------------
   Parent:
     SOA_0           SOA_1 ------------------------> SOA_2
     RRSIG_par(SOA)  RRSIG_par(SOA) ---------------> RRSIG_par(SOA)
     DS_K_1          DS_K_1 ----------------------->
                     DS_K_2 -----------------------> DS_K_2
     RRSIG_par(DS)   RRSIG_par(DS) ----------------> RRSIG_par(DS)

   Child:
     SOA_0 -----------------------> SOA_1 ---------------------------->
     RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------>

     DNSKEY_K_1 ------------------> DNSKEY_K_2 ----------------------->
     DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ---------------------->
     RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) --------------->
   --------------------------------------------------------------------

              Figure 5: Stages of Deployment for a Double-DS
                         Key Signing Key Rollover

   When the child zone wants to roll, it notifies the parent during the
   "new DS" phase and submits the new key (or the corresponding DS) to
   the parent.  The parent publishes DS_K_1 and DS_K_2, pointing to
   DNSKEY_K_1 and DNSKEY_K_2, respectively.  During the rollover ("new
   DNSKEY" phase), which can take place as soon as the new DS set
   propagated through the DNS, the child replaces DNSKEY_K_1 with
   DNSKEY_K_2.  If the old key has expired from caches, at the "DS
   removal" phase the parent can be notified that the old DS record can
   be deleted.

   The drawbacks of this scheme are that during the "new DS" phase, the
   parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2
   using the DNS, as DNSKEY_K_2 is not yet published.  Besides, we
   introduce a "security lame" key (see Section 4.3.3).  Finally, the
   child-parent interaction consists of two steps.  The "Double
   Signature" method only needs one interaction.

Top      Up      ToC       Page 26 
4.1.2.1.  Special Considerations for RFC 5011 KSK Rollover

   The scenario sketched above assumes that the KSK is not in use as a
   trust anchor but that validating name servers exclusively depend on
   the parental DS record to establish the zone's security.  If it is
   known that validating name servers have configured trust anchors,
   then that needs to be taken into account.  Here, we assume that zone
   administrators will deploy RFC 5011 [RFC5011] style rollovers.

   RFC 5011 style rollovers increase the duration of key rollovers: The
   key to be removed must first be revoked.  Thus, before the DNSKEY_K_1
   removal phase, DNSKEY_K_1 must be published for one more Maximum Zone
   TTL with the REVOKE bit set.  The revoked key must be self-signed, so
   in this phase the DNSKEY RRset must also be signed with DNSKEY_K_1.

4.1.3.  Single-Type Signing Scheme Key Rollover

   The rollover of a key when a Single-Type Signing Scheme is used is
   subject to the same requirement as the rollover of a KSK or ZSK:
   During any stage of the rollover, the chain of trust needs to
   continue to validate for any combination of data in the zone as well
   as data that may still live in distant caches.

   There are two variants for this rollover.  Since the choice for a
   Single-Type Signing Scheme is motivated by operational simplicity, we
   describe the most straightforward rollover scheme first.

   -------------------------------------------------------------------
     initial           new DNSKEY      DS change     DNSKEY removal
   -------------------------------------------------------------------
   Parent:
     SOA_0 --------------------------> SOA_1 ---------------------->
     RRSIG_par(SOA) -----------------> RRSIG_par(SOA) ------------->
     DS_S_1 -------------------------> DS_S_2 --------------------->
     RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ---------->

   Child:
     SOA_0             SOA_1 ----------------------> SOA_2
     RRSIG_S_1(SOA)    RRSIG_S_1(SOA) ------------->
                       RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA)
     DNSKEY_S_1        DNSKEY_S_1 ----------------->
                       DNSKEY_S_2 -----------------> DNSKEY_S_2
     RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ---------->
                       RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY)
   -------------------------------------------------------------------

             Figure 6: Stages of the Straightforward Rollover
                      in a Single-Type Signing Scheme

Top      Up      ToC       Page 27 
   initial:  Parental DS points to DNSKEY_S_1.  All RRsets in the zone
      are signed with DNSKEY_S_1.

   new DNSKEY:  A new key (DNSKEY_S_2) is introduced, and all the RRsets
      are signed with both DNSKEY_S_1 and DNSKEY_S_2.

   DS change:  After the DNSKEY RRset with the two keys had time to
      propagate into distant caches (that is, the key set exclusively
      containing DNSKEY_S_1 has been expired), the parental DS record
      can be changed.

   DNSKEY removal:  After the DS RRset containing DS_S_1 has expired
      from distant caches, DNSKEY_S_1 can be removed from the DNSKEY
      RRset.

   In this first variant, the new signatures and new public key are
   added to the zone.  Once they are propagated, the DS at the parent is
   switched.  If the old DS has expired from the caches, the old
   signatures and old public key can be removed from the zone.

   This rollover has the drawback that it introduces double signatures
   over all data of the zone.  Taking these zone size considerations
   into account, it is possible to not introduce the signatures made
   with DNSKEY_S_2 at the "new DNSKEY" step.  Instead, signatures of
   DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an
   additional stage between the "DS change" and "DNSKEY removal" step:
   After the DS RRset containing DS_S_1 has expired from distant caches,
   the signatures can be swapped.  Only after the new signatures made
   with DNSKEY_S_2 have been propagated can the old public key
   DNSKEY_S_1 be removed from the DNSKEY RRset.

   The second variant of the Single-Type Signing Scheme Key rollover is
   the Double-DS rollover.  In this variant, one introduces a new DNSKEY
   into the key set and submits the new DS to the parent.  The new key
   is not yet used to sign RRsets.  The signatures made with DNSKEY_S_1
   are replaced with signatures made with DNSKEY_S_2 at the moment that
   DNSKEY_S_2 and DS_S_2 have been propagated.

Top      Up      ToC       Page 28 
 -----------------------------------------------------------------------
   initial            new DS         new RRSIG         DS removal
 -----------------------------------------------------------------------
 Parent:
   SOA_0              SOA_1 -------------------------> SOA_2
   RRSIG_par(SOA)     RRSIG_par(SOA) ----------------> RRSIG_par(SOA)
   DS_S_1             DS_S_1 ------------------------>
                      DS_S_2 ------------------------> DS_S_2
   RRSIG_par(DS)      RRSIG_par(DS) -----------------> RRSIG_par(DS)

 Child:
   SOA_0              SOA_1          SOA_2             SOA_3
   RRSIG_S_1(SOA)     RRSIG_S_1(SOA) RRSIG_S_2(SOA)    RRSIG_S_2(SOA)

   DNSKEY_S_1         DNSKEY_S_1     DNSKEY_S_1
                      DNSKEY_S_2     DNSKEY_S_2        DNSKEY_S_2
   RRSIG_S_1 (DNSKEY)                RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
 -----------------------------------------------------------------------

       Figure 7: Stages of Deployment for a Double-DS Rollover in a
                        Single-Type Signing Scheme

4.1.4.  Algorithm Rollovers

   A special class of key rollovers is the one needed for a change of
   signature algorithms (either adding a new algorithm, removing an old
   algorithm, or both).  Additional steps are needed to retain integrity
   during this rollover.  We first describe the generic case; special
   considerations for rollovers that involve trust anchors and single-
   type keys are discussed later.

   There exist both a conservative and a liberal approach for algorithm
   rollover.  This has to do with Section 2.2 of RFC 4035 [RFC4035]:

      There MUST be an RRSIG for each RRset using at least one DNSKEY
      of each algorithm in the zone apex DNSKEY RRset.  The apex
      DNSKEY RRset itself MUST be signed by each algorithm appearing
      in the DS RRset located at the delegating parent (if any).

   The conservative approach interprets this section very strictly,
   meaning that it expects that every RRset has a valid signature for
   every algorithm signaled by the zone apex DNSKEY RRset, including
   RRsets in caches.  The liberal approach uses a more loose
   interpretation of the section and limits the rule to RRsets in the
   zone at the authoritative name servers.  There is a reasonable
   argument for saying that this is valid, because the specific section
   is a subsection of Section 2 ("Zone Signing") of RFC 4035.

Top      Up      ToC       Page 29 
   When following the more liberal approach, algorithm rollover is just
   as easy as a regular Double-Signature KSK rollover (Section 4.1.2).
   Note that the Double-DS KSK rollover method cannot be used, since
   that would introduce a parental DS of which the apex DNSKEY RRset has
   not been signed with the introduced algorithm.

   However, there are implementations of validators known to follow the
   more conservative approach.  Performing a Double-Signature KSK
   algorithm rollover will temporarily make your zone appear as Bogus by
   such validators during the rollover.  Therefore, the rollover
   described in this section will explain the stages of deployment and
   will assume that the conservative approach is used.

   When adding a new algorithm, the signatures should be added first.
   After the TTL of RRSIGs has expired and caches have dropped the old
   data covered by those signatures, the DNSKEY with the new algorithm
   can be added.

   After the new algorithm has been added, the DS record can be
   exchanged using Double-Signature KSK rollover.

   When removing an old algorithm, the DS for the algorithm should be
   removed from the parent zone first, followed by the DNSKEY and the
   signatures (in the child zone).

   Figure 8 describes the steps.

Top      Up      ToC       Page 30 
   ----------------------------------------------------------------
    initial              new RRSIGs           new DNSKEY
   ----------------------------------------------------------------
   Parent:
    SOA_0 -------------------------------------------------------->
    RRSIG_par(SOA) ----------------------------------------------->
    DS_K_1 ------------------------------------------------------->
    RRSIG_par(DS_K_1) -------------------------------------------->

   Child:
    SOA_0                SOA_1                SOA_2
    RRSIG_Z_10(SOA)      RRSIG_Z_10(SOA)      RRSIG_Z_10(SOA)
                         RRSIG_Z_11(SOA)      RRSIG_Z_11(SOA)

    DNSKEY_K_1           DNSKEY_K_1           DNSKEY_K_1
                                              DNSKEY_K_2
    DNSKEY_Z_10          DNSKEY_Z_10          DNSKEY_Z_10
                                              DNSKEY_Z_11
    RRSIG_K_1(DNSKEY)    RRSIG_K_1(DNSKEY)    RRSIG_K_1(DNSKEY)
                                              RRSIG_K_2(DNSKEY)

   ----------------------------------------------------------------
    new DS               DNSKEY removal       RRSIGs removal
   ----------------------------------------------------------------
   Parent:
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->

   Child:
    -------------------> SOA_3                SOA_4
    -------------------> RRSIG_Z_10(SOA)
    -------------------> RRSIG_Z_11(SOA)      RRSIG_Z_11(SOA)

    ------------------->
    -------------------> DNSKEY_K_2           DNSKEY_K_2
    ------------------->
    -------------------> DNSKEY_Z_11          DNSKEY_Z_11
    ------------------->
    -------------------> RRSIG_K_2(DNSKEY)    RRSIG_K_2(DNSKEY)
   ----------------------------------------------------------------

        Figure 8: Stages of Deployment during an Algorithm Rollover

Top      Up      ToC       Page 31 
   initial:  Describes the state of the zone before any transition is
      done.  The number of the keys may vary, but all keys (in DNSKEY
      records) for the zone use the same algorithm.

   new RRSIGs:  The signatures made with the new key over all records in
      the zone are added, but the key itself is not.  This step is
      needed to propagate the signatures created with the new algorithm
      to the caches.  If this is not done, it is possible for a resolver
      to retrieve the new DNSKEY RRset (containing the new algorithm)
      but to have RRsets in its cache with signatures created by the old
      DNSKEY RRset (i.e., without the new algorithm).

      The RRSIG for the DNSKEY RRset does not need to be pre-published
      (since these records will travel together) and does not need
      special processing in order to keep them synchronized.

   new DNSKEY:  After the old data has expired from caches, the new key
      can be added to the zone.

   new DS:  After the cache data for the old DNSKEY RRset has expired,
      the DS record for the new key can be added to the parent zone and
      the DS record for the old key can be removed in the same step.

   DNSKEY removal:  After the cache data for the old DS RRset has
      expired, the old algorithm can be removed.  This time, the old key
      needs to be removed first, before removing the old signatures.

   RRSIGs removal:  After the cache data for the old DNSKEY RRset has
      expired, the old signatures can also be removed during this step.

   Below, we deal with a few special cases of algorithm rollovers:

   1: Single-Type Signing Scheme Algorithm rollover:  when there is no
      differentiation between ZSKs and KSKs (Section 4.1.4.1).

   2: RFC 5011 Algorithm rollover:  when trust anchors can track the
      roll via RFC 5011 style rollover (Section 4.1.4.2).

   3: 1 and 2 combined:  when a Single-Type Signing Scheme Algorithm
      rollover is performed RFC 5011 style (Section 4.1.4.3).

   In addition to the narrative below, these special cases are
   represented in Figures 12, 13, and 14 in Appendix C.

Top      Up      ToC       Page 32 
4.1.4.1.  Single-Type Signing Scheme Algorithm Rollover

   If one key is used that acts as both ZSK and KSK, the same scheme and
   figure as above (Figure 8 in Section 4.1.4) applies, whereby all
   DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are
   replaced with RRSIG_S_*.  All DNSKEY_K_* records are replaced with
   DNSKEY_S_*, and all RRSIG_K_* records are replaced with RRSIG_S_*.
   The requirement to sign with both algorithms and make sure that old
   RRSIGs have the opportunity to expire from distant caches before
   introducing the new algorithm in the DNSKEY RRset is still valid.

   This is shown in Figure 12 in Appendix C.

4.1.4.2.  Algorithm Rollover, RFC 5011 Style

   Trust anchor algorithm rollover is almost as simple as a regular
   RFC 5011-based rollover.  However, the old trust anchor must be
   revoked before it is removed from the zone.

   The timeline (see Figure 13 in Appendix C) is similar to that of
   Figure 8 above, but after the "new DS" step, an additional step is
   required where the DNSKEY is revoked.  The details of this step
   ("revoke DNSKEY") are shown in Figure 9 below.

   ---------------------------------
     revoke DNSKEY
   ---------------------------------
   Parent:
     ----------------------------->
     ----------------------------->
     ----------------------------->
     ----------------------------->

   Child:
     SOA_3
     RRSIG_Z_10(SOA)
     RRSIG_Z_11(SOA)

     DNSKEY_K_1_REVOKED
     DNSKEY_K_2

     DNSKEY_Z_11
     RRSIG_K_1(DNSKEY)
     RRSIG_K_2(DNSKEY)
   ---------------------------------

      Figure 9: The Revoke DNSKEY State That Is Added to an Algorithm
                     Rollover when RFC 5011 Is in Use

Top      Up      ToC       Page 33 
   There is one exception to the requirement from RFC 4035 quoted in
   Section 4.1.4 above: While all zone data must be signed with an
   unrevoked key, it is permissible to sign the key set with a revoked
   key.  The somewhat esoteric argument is as follows:

   Resolvers that do not understand the RFC 5011 REVOKE flag will handle
   DNSKEY_K_1_REVOKED the same as if it were DNSKEY_K_1.  In other
   words, they will handle the revoked key as a normal key, and thus
   RRsets signed with this key will validate.  As a result, the
   signature matches the algorithm listed in the DNSKEY RRset.

   Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from the
   set of trust anchors.  That is okay, since they have already added
   DNSKEY_K_2 as the new trust anchor.  Thus, algorithm 2 is the only
   signaled algorithm by now.  That is, we only need RRSIG_K_2(DNSKEY)
   to authenticate the DNSKEY RRset, and we are still compliant with
   Section 2.2 of RFC 4035: There must be an RRSIG for each RRset using
   at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.

4.1.4.3.  Single Signing Type Algorithm Rollover, RFC 5011 Style

   If a decision is made to perform an RFC 5011 style rollover with a
   Single Signing Scheme key, it should be noted that Section 2.1 of
   RFC 5011 states:

      Once the resolver sees the REVOKE bit, it MUST NOT use this key
      as a trust anchor or for any other purpose except to validate
      the RRSIG it signed over the DNSKEY RRset specifically for the
      purpose of validating the revocation.

   This means that once DNSKEY_S_1 is revoked, it cannot be used to
   validate its signatures over non-DNSKEY RRsets.  Thus, those RRsets
   should be signed with a shadow key, DNSKEY_Z_10, during the algorithm
   rollover.  The shadow key can be removed at the same time the revoked
   DNSKEY_S_1 is removed from the zone.  In other words, the zone must
   temporarily fall back to a KSK/ZSK split model during the rollover.

   In other words, the rule that at every RRset there must be at least
   one signature for each algorithm used in the DNSKEY RRset still
   applies.  This means that a different key with the same algorithm,
   other than the revoked key, must sign the entire zone.  Thus, more
   operations are needed if the Single-Type Signing Scheme is used.
   Before rolling the algorithm, a new key must be introduced with the
   same algorithm as the key that is a candidate for revocation.  That
   key can than temporarily act as a ZSK during the algorithm rollover.

Top      Up      ToC       Page 34 
   As with algorithm rollover RFC 5011 style, while all zone data must
   be signed with an unrevoked key, it is permissible to sign the key
   set with a revoked key using the same esoteric argument given in
   Section 4.1.4.2.

   The lesson of all of this is that a Single-Type Signing Scheme
   algorithm rollover using RFC 5011 is as complicated as the name of
   the rollover implies: Reverting to a split-key scheme for the
   duration of the rollover may be preferable.

4.1.4.4.  NSEC-to-NSEC3 Algorithm Rollover

   A special case is the rollover from an NSEC signed zone to an NSEC3
   signed zone.  In this case, algorithm numbers are used to signal
   support for NSEC3 but they do not mandate the use of NSEC3.
   Therefore, NSEC records should remain in the zone until the rollover
   to a new algorithm has completed and the new DNSKEY RRset has
   populated distant caches, at the end of the "new DNSKEY" stage.  At
   that point, the validators that have not implemented NSEC3 will treat
   the zone as unsecured as soon as they follow the chain of trust to
   the DS that points to a DNSKEY of the new algorithm, while validators
   that support NSEC3 will happily validate using NSEC.  Turning on
   NSEC3 can then be done during the "new DS" step: increasing the
   serial number, introducing the NSEC3PARAM record to signal that
   NSEC3-authenticated data related to denial of existence should be
   served, and re-signing the zone.

   In summary, an NSEC-to-NSEC3 rollover is an ordinary algorithm
   rollover whereby NSEC is used all the time and only after that
   rollover finished NSEC3 needs to be deployed.  The procedures are
   also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155].

4.1.5.  Considerations for Automated Key Rollovers

   As keys must be renewed periodically, there is some motivation to
   automate the rollover process.  Consider the following:

   o  ZSK rollovers are easy to automate, as only the child zone is
      involved.

   o  A KSK rollover needs interaction between the parent and child.
      Data exchange is needed to provide the new keys to the parent;
      consequently, this data must be authenticated, and integrity must
      be guaranteed in order to avoid attacks on the rollover.

Top      Up      ToC       Page 35 
4.2.  Planning for Emergency Key Rollover

   This section deals with preparation for a possible key compromise.
   It is advisable to have a documented procedure ready for those times
   when a key compromise is suspected or confirmed.

   When the private material of one of a zone's keys is compromised, it
   can be used by an attacker for as long as a valid trust chain exists.
   A trust chain remains intact for

   o  as long as a signature over the compromised key in the trust chain
      is valid, and

   o  as long as the DS RR in the parent zone points to the
      (compromised) key signing the DNSKEY RRset, and

   o  as long as the (compromised) key is anchored in a resolver and is
      used as a starting point for validation (this is generally the
      hardest to update).

   While a trust chain to a zone's compromised key exists, your
   namespace is vulnerable to abuse by anyone who has obtained
   illegitimate possession of the key.  Zone administrators have to make
   a decision as to whether the abuse of the compromised key is worse
   than having data in caches that cannot be validated.  If the zone
   administrator chooses to break the trust chain to the compromised
   key, data in caches signed with this key cannot be validated.
   However, if the zone administrator chooses to take the path of a
   regular rollover, during the rollover the malicious key holder can
   continue to spoof data so that it appears to be valid.

4.2.1.  KSK Compromise

   A compromised KSK can be used to sign the key set of an attacker's
   version of the zone.  That zone could be used to poison the DNS.

   A zone containing a DNSKEY RRset with a compromised KSK is vulnerable
   as long as the compromised KSK is configured as the trust anchor or a
   DS record in the parent zone points to it.

   Therefore, when the KSK has been compromised, the trust anchor or the
   parent DS record should be replaced as soon as possible.  It is local
   policy whether to break the trust chain during the emergency
   rollover.  The trust chain would be broken when the compromised KSK
   is removed from the child's zone while the parent still has a DS
   record pointing to the compromised KSK.  The assumption is that there

Top      Up      ToC       Page 36 
   is only one DS record at the parent.  If there are multiple DS
   records, this does not apply, although the chain of trust of this
   particular key is broken.

   Note that an attacker's version of the zone still uses the
   compromised KSK, and the presence of the corresponding DS record in
   the parent would cause the data in this zone to appear as valid.
   Removing the compromised key would cause the attacker's version of
   the zone to appear as valid and the original zone as Bogus.
   Therefore, we advise administrators not to remove the KSK before the
   parent has a DS record for the new KSK in place.

4.2.1.1.  Emergency Key Rollover Keeping the Chain of Trust Intact

   If it is desired to perform an emergency key rollover in a manner
   that keeps the chain of trust intact, the timing of the replacement
   of the KSK is somewhat critical.  The goal is to remove the
   compromised KSK as soon as the new DS RR is available at the parent.
   This means ensuring that the signature made with a new KSK over the
   key set that contains the compromised KSK expires just after the new
   DS appears at the parent.  Expiration of that signature will cause
   expiration of that key set from the caches.

   The procedure is as follows:

   1.  Introduce a new KSK into the key set; keep the compromised KSK in
       the key set.  Lower the TTL for DNSKEYs so that the DNSKEY RRset
       will expire from caches sooner.

   2.  Sign the key set, with a short validity period.  The validity
       period should expire shortly after the DS is expected to appear
       in the parent and the old DSs have expired from caches.  This
       provides an upper limit on how long the compromised KSK can be
       used in a replay attack.

   3.  Upload the DS for this new key to the parent.

   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
       to appear at the authoritative servers, and then wait as long as
       the TTL of the old DS RRs.  If necessary, re-sign the DNSKEY
       RRset and modify/extend the expiration time.

   5.  Remove the compromised DNSKEY RR from the zone, and re-sign the
       key set using your "normal" TTL and signature validity period.

Top      Up      ToC       Page 37 
   An additional danger of a key compromise is that the compromised key
   could be used to facilitate a legitimate-looking DNSKEY/DS rollover
   and/or name server changes at the parent.  When that happens, the
   domain may be in dispute.  An authenticated out-of-band and secure
   notify mechanism to contact a parent is needed in this case.

   Note that this is only a problem when the DNSKEY and/or DS records
   are used to authenticate communication with the parent.

4.2.1.2.  Emergency Key Rollover Breaking the Chain of Trust

   There are two methods to perform an emergency key rollover in a
   manner that breaks the chain of trust.  The first method causes the
   child zone to appear Bogus to validating resolvers.  The other causes
   the child zone to appear Insecure.  These are described below.

   In the method that causes the child zone to appear Bogus to
   validating resolvers, the child zone replaces the current KSK with a
   new one and re-signs the key set.  Next, it sends the DS of the new
   key to the parent.  Only after the parent has placed the new DS in
   the zone is the child's chain of trust repaired.  Note that until
   that time, the child zone is still vulnerable to spoofing: The
   attacker is still in possession of the compromised key that the DS
   points to.

   An alternative method of breaking the chain of trust is by removing
   the DS RRs from the parent zone altogether.  As a result, the child
   zone would become Insecure.  After the DS has expired from distant
   caches, the keys and signatures are removed from the child zone, new
   keys and signatures are introduced, and finally, a new DS is
   submitted to the parent.

4.2.2.  ZSK Compromise

   Primarily because there is no interaction with the parent required
   when a ZSK is compromised, the situation is less severe than with a
   KSK compromise.  The zone must still be re-signed with a new ZSK as
   soon as possible.  As this is a local operation and requires no
   communication between the parent and child, this can be achieved
   fairly quickly.  However, one has to take into account that -- just
   as with a normal rollover -- the immediate disappearance of the old
   compromised key may lead to verification problems.  Also note that
   until the RRSIG over the compromised ZSK has expired, the zone may
   still be at risk.

Top      Up      ToC       Page 38 
4.2.3.  Compromises of Keys Anchored in Resolvers

   A key can also be pre-configured in resolvers as a trust anchor.  If
   trust anchor keys are compromised, the administrators of resolvers
   using these keys should be notified of this fact.  Zone
   administrators may consider setting up a mailing list to communicate
   the fact that a SEP key is about to be rolled over.  This
   communication will of course need to be authenticated by some means,
   e.g., by using digital signatures.

   End-users faced with the task of updating an anchored key should
   always verify the new key.  New keys should be authenticated out-of-
   band, for example, through the use of an announcement website that is
   secured using Transport Layer Security (TLS) [RFC5246].

4.2.4.  Stand-By Keys

   Stand-by keys are keys that are published in your zone but are not
   used to sign RRsets.  There are two reasons why someone would want to
   use stand-by keys.  One is to speed up the emergency key rollover.
   The other is to recover from a disaster that leaves your production
   private keys inaccessible.

   The way to deal with stand-by keys differs for ZSKs and KSKs.  To
   make a stand-by ZSK, you need to publish its DNSKEY RR.  To make a
   stand-by KSK, you need to get its DS RR published at the parent.

   Assuming you have your normal DNS operation, to prepare stand-by keys
   you need to:

   o  Generate a stand-by ZSK and KSK.  Store them safely in a location
      different than the place where the currently used ZSK and KSK are
      held.

   o  Pre-publish the DNSKEY RR of the stand-by ZSK in the zone.

   o  Pre-publish the DS of the stand-by KSK in the parent zone.

   Now suppose a disaster occurs and disables access to the currently
   used keys.  To recover from that situation, follow these procedures:

   o  Set up your DNS operations and introduce the stand-by KSK into the
      zone.

   o  Post-publish the disabled ZSK and sign the zone with the stand-by
      keys.

Top      Up      ToC       Page 39 
   o  After some time, when the new signatures have been propagated, the
      old keys, old signatures, and the old DS can be removed.

   o  Generate a new stand-by key set at a different location and
      continue "normal" operation.



(page 39 continued on part 3)

Next RFC Part