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

bind 9.3结合mysql数据库

   and potentially for configuration as trusted anchors - the so called
   Secure Entry Point keys (SEP). In this document we assume a
   one-to-one mapping between KSK and SEP keys and we assume the SEP
   flag [4] to be set on KSKs.

3.1  Motivations for the KSK and ZSK Functions

   Differentiating between the KSK to ZSK functions has several
   advantages:

   o  Making the KSK stronger (i.e. using more bits in the key material)
      has little operational impact since it is only used to sign a
      small fraction of the zone data.
   o  As the KSK is only used to sign a keyset, which is most probably
      updated less frequently than other data in the zone, it can be
      stored separately from (and thus in a safer location than) the
      ZSK.
   o  A KSK can be used for longer periods.
   o  No parent/child interaction is required when ZSKs are updated.

   The KSK is used less than ZSK, once a keyset is signed with the KSK
   all the keys in the keyset can be used as ZSK. If a ZSK is
   compromised, it can be simply dropped from the keyset. The new keyset
   is then resigned with the KSK.

   Given the assumption that for KSKs the SEP flag is set, the KSK can
   be distinguished from a ZSK by examining the flag field in the DNSKEY
   RR. If the flag field is an odd number it is a KSK if it is an even
   number it is a ZSK e.g. a value of 256 and a key signing key has 257.

   The zone-signing key can be used to sign all the data in a zone on a
   regular basis. When a zone-signing key is to be rolled, no
   interaction with the parent is needed.  This allows for relatively
   short "Signature Validity Periods". That is, Signature Validity
   Periods of the order of days.

   The key-signing key is only to be used to sign the Key RR set from
   the zone apex. If a key-signing key is to be rolled over, there will
   be interactions with parties other than the zone administrator such
   as the registry of the parent zone or administrators of verifying
   resolvers that have the particular key configured as trusted entry
   points. Hence, the "Key Usage Time" of these keys can and should be
   made much longer. Although, given a long enough key, the "Key Usage
   Time" can be on the order of years we suggest to plan for a "Key
   Usage Time" of the order of a few months so that a key rollover
   remains an operational routine.





Kolkman & Gieben        Expires August 30, 2004                 [Page 7]

Internet-Draft        DNSSEC Operational Practices            March 2004


3.2  Key Security Considerations

   Keys in DNSSEC have a number of parameters which should all be chosen
   with care, the most important once are: size, algorithm and the key
   validity period (its lifetime).

3.2.1  Key Validity Period

   RFC2541 [2] describes a number of considerations with respect to the
   security of keys. The document deals with the generation, lifetime,
   size and storage of private keys.

   In Section 3 of RFC2541 [2] there are some suggestions for a key
   validity period: 13 months for long-lived keys and 36 days for
   transaction keys but suggestions for key sizes are not made.

   If we say long-lived keys are key-signing keys and transactions keys
   are zone-signing keys, these recommendations will lead to rollovers
   occurring frequently enough to become part of 'operational habits';
   the procedure does not have to be reinvented every time a key is
   replaced.

3.2.2  Key Algorithm

   We recommend you choose RSA/SHA-1 as the preferred algorithm for the
   key. RSA has been developed in an open and transparent manner. As the
   patent on RSA expired in 2001, its use is now also free. The current
   known attacks on RSA can be defeated by making your key longer. As
   the MD5 hashing algorithm is showing (theoretical) cracks, we
   recommend the usage of SHA1.

3.2.3  Key Sizes

   When choosing key sizes, zone administrators will need to take into
   account how long a key will be used and how much data will be signed
   during the key publication period. It is hard to give precise
   recommendations but Lenstra and Verheul [9] supplied the following
   table with lower bound estimates for cryptographic key sizes. Their
   recommendations are based on a set of explicitly formulated parameter
   settings, combined with existing data points about cryptosystems. For
   details we refer to the original paper.

   [Editor's Note: DSA???]








Kolkman & Gieben        Expires August 30, 2004                 [Page 8]

Internet-Draft        DNSSEC Operational Practices            March 2004


   	Year		RSA Key Sizes	Elliptic Curve Key Size
   	2000		952			132
   	2001		990			135
   	2002		1028			139
   	2003		1068			140
   	2004		1108			143

   	2005		1149			147
   	2006		1191			148
   	2007		1235			152
   	2008		1279			155
   	2009		1323			157


   	2010		1369			160
   	2011		1416			163
   	2012		1464			165
   	2013		1513			168
   	2014		1562			172

   	2015		1613			173
   	2016		1664			177
   	2017		1717			180
   	2018		1771			181
   	2019		1825			185


   	2020		1881			188
   	2021		1937			190
   	2022		1995			193
   	2023		2054			197
   	2024		2113			198

   	2025		2174			202
   	2026		2236			205
   	2027		2299			207
   	2028		2362			210
   	2029		2427			213

   For example, should you wish your key to last three years from 2003,
   check the RSA keysize values for 2006 in this table. In this case
   1191.

3.3  Key Rollovers

   Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
   cannot be used forever (see RFC2541 [2] and Section 3.2 ).  Zone
   administrators who are in the process of rolling their keys have to



Kolkman & Gieben        Expires August 30, 2004                 [Page 9]

Internet-Draft        DNSSEC Operational Practices            March 2004


   take into account 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 is when zone material signed with
   an old key is being validated by a resolver which 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 which is
   signed with a new key against an old key that lives in a local cache,
   also resulting in data being marked bogus.

   To appreciate the situation one could think of a number of
   authoritative servers that may not be instantaneously running the
   same version of a zone and a security aware non-recursive resolver
   that sits behind security aware caching forwarders.

   Note that KSK rollovers and ZSK rollovers are different. A zone-key
   rollover can be handled in two different ways: pre-publish (Section
   Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The
   pre-publish technique works because the key-signing key stays the
   same during this ZSK rollover. With this KSK a cache is able to
   validate the new keyset of a zone. With a KSK rollover a cache can
   not validate the new keyset, because it does not trust the new KSK.

   [Editors note: This needs more verbose explanation, nobody will
   appreciate the situation just yet. Help with text and examples is
   appreciated]

3.3.1  Zone-signing Key Rollovers

   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
   keysets or newly generated signatures can be verified with the keys
   still in caches. One schema uses double signatures, it is described
   in Section 3.3.1.2, the other uses key pre-publication (Section
   3.3.1.1). The pros, cons and recommendations are described in Section
   3.3.1.3.

3.3.1.1  Pre-publish Keyset Rollover

   This section shows how to perform a ZSK rollover without the need to
   sign all the data in a zone twice - the so called "prepublish
   rollover". We recommend this method because it has advantages in the
   case of 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



Kolkman & Gieben        Expires August 30, 2004                [Page 10]

Internet-Draft        DNSSEC Operational Practices            March 2004


   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. A
   small "HOWTO" for this kind of rollover can be found in Appendix B.

       normal          pre-roll         roll            after

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

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


   normal: Version 0 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.
   pre-roll: DNSKEY 11 is introduced into the keyset. Note that no
      signatures are generated with this key yet, but this does not
      secure against brute force attacks on the 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 TTL value of the
      keyset. This equates to two times the Maximum Zone TTL.
   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign
      the data in the zone exclusively  (i.e. all the signatures from
      DNSKEY 10 are removed from the zone). DNSKEY 10 remains published
      in the keyset. This way data that was loaded into caches from
      version 1 of the zone can still be verified with key sets fetched
      from version 2 of the zone.
      The minimum time that the keyset including DNSKEY 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.
   after: DNSKEY 10 is removed from the zone. The keyset, now only
      containing DNSKEY 11 is resigned with the DNSKEY 1.

   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 "after" as
   DNSKEY 12 and again a newer one, numbered 13, in "2nd after":







Kolkman & Gieben        Expires August 30, 2004                [Page 11]

Internet-Draft        DNSSEC Operational Practices            March 2004


       normal          roll            after           2nd roll        2nd after

       SOA0            SOA2            SOA3            SOA4            SOA5
       RRSIG10(SOA0)   RRSIG11(SOA2)   RRSIG11(SOA3)   RRSIG12(SOA4)   RRSIG12(SOA5)

       DNSKEY1         DNSKEY1         DNSKEY1         DNSKEY1         DNSKEY1
       DNSKEY10        DNSKEY10        DNSKEY11        DNSKEY11        DNSKEY12
       DNSKEY11        DNSKEY11        DNSKEY12        DNSKEY12        DNSKEY13
       RRSIG1(DNSKEY)  RRSIG1 (DNSKEY) RRSIG1(DNSKEY)  RRSIG1(DNSKEY)  RRSIG1(DNSKEY)
       RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)


   Note that the key introduced after the rollover 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.

   This scheme has the benefit that the key that is intended for future
   use: immediately during an emergency rollover assuming that the
   private key was stored in a physically secure manner.

3.3.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 rollover 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, this will take at least the
   maximum Zone TTL .

       normal              roll              after

       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)

   normal: Version 0 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.




Kolkman & Gieben        Expires August 30, 2004                [Page 12]

Internet-Draft        DNSSEC Operational Practices            March 2004