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

bind 源码 最新实现 linux/unix/windows平台

   referred to as Zone Signing Keys (ZSK).  In this document we assume
   that KSKs are the subset of keys that are used for key exchanges with
   the parent and potentially for configuration as trusted anchors - the
   SEP keys.  In this document we assume a one-to-one mapping between
   KSK and SEP keys and we assume the SEP flag [1] to be set on all
   KSKs.

3.1.1  Motivations for the KSK and ZSK Separation

   Differentiating between the KSK and ZSK functions has several
   advantages:






Kolkman & Gieben        Expires September 2, 2005               [Page 6]

Internet-Draft        DNSSEC Operational Practices            March 2005


   o  No parent/child interaction is required when ZSKs are updated.
   o  The KSK can be made stronger (i.e. using more bits in the key
      material).  This has little operational impact since it is only
      used to sign a small fraction of the zone data.  Also when
      verifying the KSK is only used to verify the zone's keyset.
   o  As the KSK is only used to sign a key set, which is most probably
      updated less frequently than other data in the zone, it can be
      stored separately from and in a safer location than the ZSK.
   o  A KSK can have a longer key effectivity period.

   For almost any method of key management and zone signing the KSK is
   used less frequently than the ZSK.  Once a key set is signed with the
   KSK all the keys in the key set can be used as ZSK.  If a ZSK is
   compromised, it can be simply dropped from the key set.  The new key
   set 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.

   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 "Signature
   Validity Periods" on the order of days.

   The key-signing key is only to be used to sign the DNSKEY RRs in a
   zone.  If a key-signing key is to be rolled over, there will be
   interactions with parties other than the zone administrator.  These
   can include the registry of the parent zone or administrators of
   verifying resolvers that have the particular key configured as
   trusted entry points.  Hence, the key effectivity period 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 planning for a key effectivity of the order of a few months
   so that a key rollover remains an operational routine.

3.1.2  KSKs for high level zones

   Higher level zones are generally more sensitive than lower level
   zones.  Anyone controlling or breaking the security of a zone thereby
   obtains authority over all of its sub domains (except in the case of
   resolvers that have locally configured the public key of a sub
   domain).  Therefore, extra care should be taken with high level zones
   and strong keys used.

   The root zone is the most critical of all zones.  Someone controlling
   or compromising the security of the root zone would control the



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


   entire DNS name space of all resolvers using that root zone (except
   in the case of resolvers that have locally configured the public key
   of a sub domain).  Therefore, the utmost care must be taken in the
   securing of the root zone.  The strongest and most carefully handled
   keys should be used.  The root zone private key should always be kept
   off line.

   Many resolvers will start at a root server for their access to and
   authentication of DNS data.  Securely updating the trust anchors in
   an enormous population of resolvers around the world will be
   extremely difficult.

3.2  Randomness

   Careful generation of all keys is a sometimes overlooked but
   absolutely essential element in any cryptographically secure system.
   The strongest algorithms used with the longest keys are still of no
   use if an adversary can guess enough to lower the size of the likely
   key space so that it can be exhaustively searched.  Technical
   suggestions for the generation of random keys will be found in
   RFC1750 [3].  One should carefully assess if the random number
   generator used during key generation adheres to these suggestions.

   Keys with a long effectivity period are particularly sensitive as
   they will represent a more valuable target and be subject to attack
   for a longer time than short period keys.  It is strongly recommended
   that long term key generation occur off-line in a manner isolated
   from the network via an air gap or, at a minimum, high level secure
   hardware.

3.3  Key Effectivity Period

   For various reasons keys in DNSSEC need to be changed once in a
   while.  The longer a key is in use, the greater the probability that
   it will have been compromised through carelessness, accident,
   espionage, or cryptanalysis.  Furthermore when key rollovers are too
   rare an event, they will not become part of the operational habit and
   there is risk that nobody on-site will remember the procedure for
   rollover when the need is there.

   For Key Signing Keys a reasonable key effectivity period is 13
   months, with the intent to replace them after 12 months.  An intended
   key effectivity period of a month is reasonable for Zone Signing
   Keys.

   Using 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



Kolkman & Gieben        Expires September 2, 2005               [Page 8]

Internet-Draft        DNSSEC Operational Practices            March 2005


   replaced.

   Key effectivity periods can be made very short, as in the order of a
   few minutes.  But when replacing keys one has to take the
   considerations from Section 4.1 and Section 4.2 into account.

3.4  Key Algorithm

   There are currently three different types of algorithms that can be
   used in DNSSEC: RSA, DSA and elliptic curve cryptography.  The latter
   is fairly new and still needs to be standardized for usage in DNSSEC.

   RSA has been developed in an open and transparent manner.  As the
   patent on RSA expired in 2000, its use is now also free.

   DSA has been developed by NIST.  The creation of signatures is
   roughly done at the same speed as with RSA, but is 10 to 40 times as
   slow for verification [11].

   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
   key.  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.

   In 2005 some discoveries were made that SHA-1 also has some
   weaknesses.  Currently SHA-1 is strong enough for DNSSEC.  It is
   expected that a new hashing algorithm is rolled out, before any
   attack becomes practical.

3.5  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 [10] 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 cryptographic
   systems.  For details we refer to the original paper.












Kolkman & Gieben        Expires September 2, 2005               [Page 9]

Internet-Draft        DNSSEC Operational Practices            March 2005


       Year    RSA Key Sizes       Year    RSA Key Sizes

       2000        952             2015        1613
       2001        990             2016        1664
       2002        1028            2017        1717
       2003        1068            2018        1771
       2004        1108            2019        1825


       2005        1149            2020        1881
       2006        1191            2021        1937
       2007        1235            2022        1995
       2008        1279            2023        2054
       2009        1323            2024        2113


       2026        2236            2025        2174
       2010        1369            2027        2299
       2011        1416            2028        2362
       2012        1464            2029        2427
       2013        1513
       2014        1562

   For example, should you wish your key to last three years from 2003,
   check the RSA key size values for 2006 in this table.  In this case
   it should be at least 1191 bits.

   Please keep in mind that nobody can see into the future, and that
   these key lengths are only provided here as a guide.

   When determining a key size one should take into account that a large
   key will be slower during generation and verification.  For RSA,
   verification, the most common operation, will vary roughly with the
   square of the key size; signing will vary with the cube of the key
   size length; and key generation will vary with the fourth power of
   the modulus length.  Besides larger keys will increase the sizes of
   the RRSIG and DNSKEY records and will therefore increase the chance
   of DNS UDP packet overflow.  Also see Section 3.1.1 for a discussion
   of how keys serving different roles (ZSK v.  KSK) may need different
   key strengths.

3.6  Private Key Storage

   It is recommended that, where possible, zone private keys and the
   zone file master copy be kept and used in off-line, non-network
   connected, physically secure machines only.  Periodically an
   application can be run to add authentication to a zone by adding
   RRSIG and NSEC RRs.  Then the augmented file can be transferred,



Kolkman & Gieben        Expires September 2, 2005              [Page 10]

Internet-Draft        DNSSEC Operational Practices            March 2005


   perhaps by sneaker-net, to the networked zone primary server machine.

   The ideal situation is to have a one way information flow to the
   network to avoid the possibility of tampering from the network.
   Keeping the zone master file on-line on the network and simply
   cycling it through an off-line signer does not do this.  The on-line
   version could still be tampered with if the host it resides on is
   compromised.  For maximum security, the master copy of the zone file
   should be off net and should not be updated based on an unsecured
   network mediated communication.

   In general keeping a zone-file off-line will not be practical and the
   machines on which zone files are maintained will be connected to a
   network.  Operators are advised to take security measures to shield
   unauthorized access to the master copy.

   For dynamically updated secured zones [5] both the master copy and
   the private key that is used to update signatures on updated RRs will
   need to be on line.

4.  Signature generation, Key Rollover and Related Policies

4.1  Time in DNSSEC

   Without DNSSEC all times in DNS are relative.  The SOA RR's refresh,
   retry and expiration timers are counters that are used to determine
   the time elapsed after a slave server synchronized (or tried to
   synchronize) with a master server.  The Time to Live (TTL) value and
   the SOA RR minimum TTL parameter [6] are used to determine how long a
   forwarder should cache data after it has been fetched from an
   authoritative server.  By using a signature validity period, DNSSEC
   introduces the notion of an absolute time in the DNS.  Signatures in
   DNSSEC have an expiration date after which the signature is marked as
   invalid and the signed data is to be considered Bogus.

4.1.1  Time Considerations

   Because of the expiration of signatures, one should consider the
   following:
   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
      of your signature validity period.
         If the TTL would be of similar order as the signature validity
         period, then all RRsets fetched during the validity period
         would be cached until the signature expiration time.  Section
         7.1 of [2] suggests that "the resolver may use the time
         remaining before expiration of the signature validity period of
         a signed RRset as an upper bound for the TTL".  As a result
         query load on authoritative servers would peak at signature



Kolkman & Gieben        Expires September 2, 2005              [Page 11]

Internet-Draft        DNSSEC Operational Practices            March 2005


         expiration time, as this is also the time at which records
         simultaneously expire from caches.
         To avoid query load peaks we suggest the TTL on all the RRs in
         your zone to be at least a few times smaller than your
         signature validity period.
   o  We suggest the signature publication period to be at least one
      maximum TTL smaller than the signature validity period.
         Resigning a zone shortly before the end of the signature
         validity period may cause simultaneous expiration of data from
         caches.  This in turn may lead to peaks in the load on
         authoritative servers.
   o  We suggest the minimum zone TTL to be long enough to both fetch
      and verify all the RRs in the authentication chain.  A low TTL
      could cause two problems:
         1.  During validation, some data may expire before the