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

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

   for verification can be obtained.

   The responsibility for maintaining the chain of trust is shared by
   administrators of secured zones in the chain of trust.  This is most
   obvious in the case of a 'key compromise' when a trade off between
   maintaining a valid chain of trust and replacing the compromised keys
   as soon as possible must be made.  Then zone administrators will have
   to make a trade off, between keeping the chain of trust intact -
   thereby allowing for attacks with the compromised key - or to
   deliberately break the chain of trust and making secured sub domains
   invisible to security aware resolvers.  Also see Section 4.3.


3.  Keys Generation and Storage

   This section describes a number of considerations with respect to the
   security of keys.  It deals with the generation, effectivity period,
   size and storage of private keys.

3.1.  Zone and Key Signing Keys

   The DNSSEC validation protocol does not distinguish between different
   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
   practice operators use Key Signing and Zone Signing Keys and use the
   so-called (Secure Entry Point) SEP [3] flag to distinguish between
   them during operations.  The dynamics and considerations are
   discussed below.

   To make zone re-signing and key rollover procedures easier to



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


   implement, it is possible to use one or more keys as Key Signing Keys
   (KSK).  These keys will only sign the apex DNSKEY RRSet in a zone.
   Other keys can be used to sign all the RRSets in a zone and are
   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 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:

   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 the KSK is
      only used to verify the zone's key set, not for other RRSets in
      the zone.
   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 re-signed 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 secure
   entry points.  Hence, the key effectivity period of these keys can
   and should be made much longer.  Although, given a long enough key,



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


   the Key Effectivity Period 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, in which case this, and only this, sub domain wouldn't be
   affected by the compromise of the parent zone).  Therefore, extra
   care should be taken with high level zones and strong keys should
   used.

   The root zone is the most critical of all zones.  Someone controlling
   or compromising the security of the root zone would control the
   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.  Key Generation

   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 RFC
   4086 [15].  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.





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


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.

   From a purely operational perspective a reasonable key effectivity
   period for Key Signing Keys 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.

   For key sizes that matches these effectivity periods see Section 3.5.

   As argued in Section 3.1.2 securely updating trust anchors will be
   extremely difficult.  On the other hand the "operational habit"
   argument does also apply to trust anchor reconfiguration.  If a short
   key-effectivity period is used and the trust anchor configuration has
   to be revisited on a regular basis the odds that the configuration
   tends to be forgotten is smaller.  The trade-off is against a system
   that is so dynamic that administrators of the validating clients will
   not be able to follow the modifications.

   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 has yet 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 takes
   roughly the same time as with RSA, but is 10 to 40 times as slow for
   verification [18].

   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 SHA-1.




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


   At the time of publication it is known that the SHA-1 hash has
   cryptanalysis issues.  There is work in progress on addressing these
   issues.  We recommend the use of public key algorithms based on
   hashes stronger than SHA-1, e.g.  SHA-256, as soon as these
   algorithms are available in protocol specifications (See [20] and
   [21] ) and implementations.

3.5.  Key Sizes

   When choosing key sizes, zone administrators will need to take into
   account how long a key will be used, how much data will be signed
   during the key publication period (See Section 8.10 of [18]) and,
   optionally, how large the key size of the parent is.  As the chain of
   trust really is "a chain", there is not much sense in making one of
   the keys in the chain several times larger then the others.  As
   always, it's the weakest link that defines the strength of the entire
   chain.  Also see Section 3.1.1 for a discussion of how keys serving
   different roles (ZSK v.  KSK) may need different key sizes.

   Generating a key of the correct size is a difficult problem, RFC 3766
   [14] tries to deal with that problem.  The first part of the
   selection procedure in Section 1 of the RFC states:

      1. Determine the attack resistance necessary to satisfy the
         security requirements of the application.  Do this by
         estimating the minimum number of computer operations that
         the attacker will be forced to do in order to compromise
         the security of the system and then take the logarithm base
         two of that number.  Call that logarithm value "n".

         A 1996 report recommended 90 bits as a good all-around choice
         for system security.  The 90 bit number should be increased
         by about 2/3 bit/year, or about 96 bits in 2005.

   [14] goes on to explain how this number "n" can be used to calculate
   the key sizes in public key cryptography.  This culminated in the
   table given below (slightly modified for our purpose):














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


      +-------------+-----------+--------------+
      | System      |           |              |
      | requirement | Symmetric | RSA or DSA   |
      | for attack  | key size  | modulus size |
      | resistance  | (bits)    | (bits)       |
      | (bits)      |           |              |
      +-------------+-----------+--------------+
      |     70      |     70    |      947     |
      |     80      |     80    |     1228     |
      |     90      |     90    |     1553     |
      |    100      |    100    |     1926     |
      |    150      |    150    |     4575     |
      |    200      |    200    |     8719     |
      |    250      |    250    |    14596     |
      +-------------+-----------+--------------+

   The key sizes given are rather large.  This is because these keys are
   resilient against a trillionaire attacker.  Assuming this rich
   attacker will not attack your key and that the key is rolled over
   once a year, we come to the following recommendations about KSK
   sizes; 1024 bits low value domains, 1300 for medium value and 2048
   for the high value domains.

   Whether a domain is of low, medium, high value depends solely on the
   views of the zone owner.  One could for instance view leaf nodes in
   the DNS as of low value and TLDs or the root zone of high value.  The
   suggested key sizes should be safe for the next 5 years.

   As ZSKs can be rolled over more easily (and thus more often) the key
   sizes can be made smaller.  But as said in the introduction of this
   paragraph, making the ZSKs' key sizes too small (in relation to the
   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
   size to about 100 bits.

   Note that nobody can see into the future, and that these key sizes
   are only provided here as a guide.  Further information can be found
   in [17] and Section 7.5 of [18].  It should be noted though that [17]
   is already considered overly optimistic about what key sizes are
   considered safe.

   One final note concerning key sizes.  Larger keys will increase the