draft-ietf-dnsop-dnssec-operational-practices-08.txt

来自「非常好的dns解析软件」· 文本 代码 · 共 1,507 行 · 第 1/5 页

       DNSKEY11            DNSKEY11            DNSKEY12
       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)


       new RRSIGs (II)     new DNSKEY (II)

       SOA3                SOA4
       RRSIG12(SOA3)       RRSIG12(SOA4)

       DNSKEY1             DNSKEY1
       DNSKEY11            DNSKEY12
       DNSKEY12            DNSKEY13
       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)


   Pre-Publish 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.2.1.2.  Double Signature Zone Signing Key Rollover

   This section shows how to perform a ZSK key rollover using the double
   zone data signature scheme, aptly named "double sig 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 maximum Zone TTL.











Kolkman & Gieben        Expires September 7, 2006              [Page 17]

Internet-Draft        DNSSEC Operational Practices            March 2006


   Double Signature Zone Signing Key Rollover involves three stages as
   follows:

       initial             new DNSKEY         DNSKEY removal

       SOA0                SOA1               SOA2
       RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
                           RRSIG11(SOA1)

       DNSKEY1             DNSKEY1            DNSKEY1
       DNSKEY10            DNSKEY10           DNSKEY11
                           DNSKEY11
       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
                           RRSIG11(DNSKEY)

   initial: Initial Version of the zone: DNSKEY 1 is the key signing
      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
      signing key.
   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
      introduced into the key set and all the data in the zone is signed
      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
      continue until all data from version 0 of the zone has expired
      from remote caches.  This will take at least the maximum Zone TTL
      of version 0 of the zone.
   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
      signatures from DNSKEY 10 are removed from the zone.  The key set,
      now only containing DNSKEY 11, is re-signed with DNSKEY 1.

   At every instance, RRSIGs from the previous version of the zone can
   be verified with the DNSKEY RRSet from the current version and the
   other way around.  The data from the current version can be verified
   with the data from the previous version of the zone.  The duration of
   the "new DNSKEY" phase and the period between rollovers should be at
   least the Maximum Zone TTL.

   Making sure that the "new DNSKEY" phase lasts until the signature
   expiration time of the data in initial version of the zone is
   recommended.  This way all caches are cleared of the old signatures.
   However, this duration could be considerably longer than the Maximum
   Zone TTL, making the rollover a lengthy procedure.

   Note that in this example we assumed that the zone was not modified
   during the rollover.  New data can be introduced in the zone as long
   as it is signed with both keys.






Kolkman & Gieben        Expires September 7, 2006              [Page 18]

Internet-Draft        DNSSEC Operational Practices            March 2006


4.2.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 available for cryptanalysis
      attacks.  A small disadvantage is that this process requires four
      steps.  Also the pre-publish scheme involves more parental work
      when used for KSK rollovers as explained in Section 4.2.3.
   Double Signature Zone-signing Key Rollover: The drawback of this
      signing scheme 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
      steps.

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


       initial        new DNSKEY        DS change       DNSKEY removal
     Parent:
       SOA0           -------->         SOA1            -------->
       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
       DS1            -------->         DS2             -------->
       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->


     Child:
       SOA0            SOA1             -------->       SOA2
       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
                                        -------->
       DNSKEY1         DNSKEY1          -------->       DNSKEY2
                       DNSKEY2          -------->
       DNSKEY10        DNSKEY10         -------->       DNSKEY10
       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
                       RRSIG2 (DNSKEY)  -------->
       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)

   Stages of Deployment for Key Signing Key Rollover.







Kolkman & Gieben        Expires September 7, 2006              [Page 19]

Internet-Draft        DNSSEC Operational Practices            March 2006


   initial: Initial version of the zone.  The parental DS points to
      DNSKEY1.  Before the rollover starts the child will have to verify
      what the TTL is of the DS RR that points to DNSKEY1 - 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, DNSKEY2.  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 DNSKEY2.  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 DS1 with DS2.
   DNSKEY removal: DNSKEY1 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 premises that
   the parent only has one DS RR (per algorithm) per zone.  An
   alternative mechanism has been considered.  Using an established
   trust relation, 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
   RRs at the parent.  Since at the moment of writing the protocol for
   this interaction has not been developed, further discussion is out of
   scope for this document.

4.2.3.  Difference Between ZSK and KSK Rollovers

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

   A zone key rollover can be handled in two different ways: pre-publish
   (Section Section 4.2.1.1) and double signature (Section
   Section 4.2.1.2).

   As the KSK is used to validate the key set and because the KSK is not
   changed during a ZSK rollover, a cache is able to validate the new
   key set of the zone.  The pre-publish method would also work for a
   KSK rollover.  The records that are to be pre-published are the
   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
   We first describe the rollover scheme and then indicate these
   drawbacks.








Kolkman & Gieben        Expires September 7, 2006              [Page 20]

Internet-Draft        DNSSEC Operational Practices            March 2006


     initial         new DS           new DNSKEY      DS/DNSKEY removal
   Parent:
     SOA0            SOA1             -------->       SOA2
     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
     DS1             DS1              -------->       DS2
                     DS2              -------->
     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)



   Child:
     SOA0            -------->        SOA1            SOA1
     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
                     -------->
     DNSKEY1         -------->        DNSKEY2         DNSKEY2
                     -------->
     DNSKEY10        -------->        DNSKEY10        DNSKEY10
     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)

   Stages of Deployment for a Pre-publish 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 DS1 and DS2, pointing to DNSKEY1
   and DNSKEY2 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 DNSKEY1 with DNSKEY2.  Immediately after that
   ("DS/DNSKEY removal" phase) it can notify the parent 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 DS2 RR and DNSKEY2 using
   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
   "security lame" key (See Section 4.4.3).  Finally the child-parent
   interaction consists of two steps.  The "double signature" method
   only needs one interaction.

4.2.4.  Automated Key Rollovers

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

   o  ZSK rollovers are easy to automate as only the child zone is
      involved.
   o  A KSK rollover needs interaction between parent and child.  Data
      exchange is needed to provide the new keys to the parent,
      consequently, this data must be authenticated and integrity must



Kolkman & Gieben        Expires September 7, 2006              [Page 21]

Internet-Draft        DNSSEC Operational Practices            March 2006


      be guaranteed in order to avoid attacks on the rollover.

4.3.  Planning for Emergency Key Rollover

   This section deals with preparation for a possible key compromise.
   Our advice is to have a documented procedure ready for when a key
   compromise is suspected or confirmed.

   When the private material of one of your keys is compromised it can
   be used 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,
   o  as long as a parental DS RR (and signature) points to the
      compromised key,
   o  as long as the 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 your compromised key exists, your name-space
   is vulnerable to abuse by anyone who has obtained illegitimate
   possession of the key.  Zone operators have to make a trade off if
   the abuse of the compromised key is worse than having data in caches
   that cannot be validated.  If the zone operator 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 roll-over, the malicious key holder can
   spoof data so that it appears to be valid.