[DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13

[Matthijs Mekking <[e-mail]>]

Hi all,

The document draft-ietf-dnsop-rfc464bis-13 has seen some issues while
being in AUTH and RCF-EDITOR state. This e-mail will list all the
suggested changes to address those issues.


* Issue in section 4.1.2.  Key Signing Key Rollovers

There is a missing necessary wait: The old DNSKEY RRset must expire from
caches before the parent can change the DS RRset.

Old text:

   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.

New text:

   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
      generates a second KSK, DNSKEY_K_2, introduces it into the key
      set, and signs the new key set with both the old and new KSKs.
      The minimum duration of this phase is the time it takes for
      the data to propagate to the authoritative servers, plus TTL value
      of the key set.

   DS change: The new key is provided to the parent. The child will
      have to wait until the parent replaces DS_K_1 with DS_K_2.  After
      the new 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.


* Issue in section 4.1.3.  Single Type Signing Scheme Key Rollover

Not all signatures can skip pre-publication, the new key must sign the
DNSKEY RRset before the DS change, even if signing the rest of the zone
is delayed.

Old text:

   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, the old public key DNSKEY_S_1
   can be removed from the DNSKEY RRset.

New text:

   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, except for the signature
   over the DNSKEY RRset.  Instead, signatures of DNSKEY_S_1 in the rest
   of the zone 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, the old public key DNSKEY_S_1
   can be removed from the DNSKEY RRset.


* Issue on Section 4.3.5.1.  Cooperating DNS operators

The decision is to handle only one scenario, the alternative approach
from the appendix, and remove the utterly complex, drawback heavy
scenario that is now described first in the document. I'll post the old
and new contents of the section below (warning: it is a bit long). In
addition, Appendix D.  Transition Figure for Changing DNS Operators is
removed.

Old text:

   In this scenario, it is assumed that the losing operator will not
   pass any private key material to the gaining operator (that would
   constitute a trivial case) but is otherwise fully cooperative.

   In this environment, the change could be made with a Pre-Publish ZSK
   rollover whereby the losing operator pre-publishes the ZSK of the
   gaining operator, combined with a Double Signature KSK rollover where
   the two registrars exchange public keys and independently generate a
   signature over those key sets that they combine and both publish in
   their copy of the zone.  Once that is done they can use their own
   private keys to sign any of their zone content during the transfer.

    ------------------------------------------------------------
    initial            |        pre-publish                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A                            DS_A
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          NS_B               RRSIG_Z_B(NS)
                            RRSIG_Z_A(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_A
                            DNSKEY_K_B         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
                            RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

    ------------------------------------------------------------
          redelegation                 |   post migration      |
    ------------------------------------------------------------
    Parent:
              NS_B                           NS_B
              DS_B                           DS_B
    ------------------------------------------------------------
    Child at A:        Child at B:           Child at B:

     SOA_A1             SOA_B0                SOA_B1
     RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)        RRSIG_Z_B(SOA)

     NS_A               NS_B                  NS_B
     NS_B               RRSIG_Z_B(NS)         RRSIG_Z_B(NS)
     RRSIG_Z_A(NS)

     DNSKEY_Z_A         DNSKEY_Z_A
     DNSKEY_Z_B         DNSKEY_Z_B            DNSKEY_Z_B
     DNSKEY_K_A         DNSKEY_K_A
     DNSKEY_K_B         DNSKEY_K_B            DNSKEY_K_B
     RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
     RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)     RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

               Figure 10: Rollover for cooperating operators

   In this figure A denotes the losing operator and B the gaining
   operator.  RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is
   produced with a KSK, the appended A or B indicates the producers of
   the key pair.  "Child at A" is how the zone content is represented by
   the losing DNS operator and "Child at B" is how the zone content is
   represented by the gaining DNS operator.

   The zone is initially delegated from the parent to the name servers
   of operator A. Operator A uses his own ZSK and KSK to sign the zone.
   The cooperating operator A will pre-publish the new NS record and the
   ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset
   generated by the KSK of B. Operator B needs to publish the same
   DNSKEY RRset.  When that DNSKEY RRset has populated the caches, the
   re-delegation can be made, which involves adjusting the NS and DS
   records in the parent zone to point to operator B. And after all
   DNSSEC records related to A have expired from the caches, operator B
   can stop publishing the keys and signatures belonging to operator A
   and vice versa.

   The requirement to exchange signatures has a couple of drawbacks.  It
   requires more operational overhead, because not only the operators
   have to exchange public keys, they also have to exchange the
   signatures of the new DNSKEY RRset.  This drawback does not exist if
   the Double Signature KSK rollover is replaced with a Double-DS KSK
   rollover.  See Figure 15 in Appendix D for the diagram.

   Thus, if the registry and registrars allow DS records to be published
   that do not point to a published DNSKEY in the child zone, the
   Double-DS KSK rollover is preferred (see Figure 5), in combination
   with the Pre-Publish ZSK rollover.  This does not require sharing the
   KSK signatures between the operators, but both operators still have
   to publish each others ZSKs.

New text:

   In this scenario, it is assumed that the losing operator will not
   pass any private key material to the gaining operator (that would
   constitute a trivial case) but is otherwise fully cooperative.

   In this environment, the change could be made with a Pre-Publish ZSK
   rollover whereby the losing operator pre-publishes the ZSK of the
   gaining operator, combined with a Double-DS KSK rollover.  Once that
   is done they can use their own private keys to sign any of their zone
   content during the transfer.

    ------------------------------------------------------------
    initial             |        new DS and pre-publish        |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A                            DS_A DS_B
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          RRSIG_Z_A(NS)      RRSIG_Z_B(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

    ------------------------------------------------------------
          re-delegation                |   post migration      |
    ------------------------------------------------------------
    Parent:
              NS_B                           NS_B
              DS_A DS_B                      DS_B
    ------------------------------------------------------------
    Child at A:        Child at B:           Child at B:

     SOA_A1             SOA_B0                SOA_B1
     RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)        RRSIG_Z_B(SOA)

     NS_B               NS_B                  NS_B
     RRSIG_Z_A(NS)      RRSIG_Z_B(NS)         RRSIG_Z_B(NS)

     DNSKEY_Z_A         DNSKEY_Z_A
     DNSKEY_Z_B         DNSKEY_Z_B            DNSKEY_Z_B
     DNSKEY_K_A         DNSKEY_K_B            DNSKEY_K_B
     RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)     RRSIG_K_B(DNSKEY)

    ------------------------------------------------------------

               Figure 10: Rollover for cooperating operators

   In this figure A denotes the losing operator and B the gaining
   operator.  RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is
   produced with a KSK, the appended A or B indicates the producers of
   the key pair.  "Child at A" is how the zone content is represented by
   the losing DNS operator and "Child at B" is how the zone content is
   represented by the gaining DNS operator.

   The zone is initially delegated from the parent to the name servers
   of operator A. Operator A uses his own ZSK and KSK to sign the zone.
   In the second stage, 'new DS and pre-publish', the cooperating
   operator A will pre-publish the ZSK of operator B, while the new
   operator B publishes the ZSK of operator A. Both operators sign their
   zone with their own ZSKs and KSKs.  At the same time, operator B can
   pre-publish the new DS record, DS_B, that delegates to the KSK of
   operator B.

   When the old DNSKEY and DS RRsets have expired from the caches, i.e.
   all the resolvers are still using the delegation of the old operator
   but are prepared to trust the delegation to the new operator, the
   re-delegation can be made.  This involves adjusting the NS RRset in
   the parent zone to point to operator B. To ensure resolvers switch
   from A to B, operator A should also change its NS records to point to
   operator B. In the post migration stage, when all RRSIG records
   related to A have expired from the caches, operator B can stop
   publishing the keys belonging to operator A and the DS record
   belonging to operator A, DS_A, can be removed from the parent zone.