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

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

4.3.1.  KSK Compromise

   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
   as long as the compromised KSK is configured as trust anchor or a
   parental DS points to it.

   A compromised KSK can be used to sign the key set of an attacker's
   zone.  That zone could be used to poison the DNS.

   Therefore when the KSK has been compromised, the trust anchor or the
   parental DS, should be replaced as soon as possible.  It is local
   policy whether to break the trust chain during the emergency
   rollover.  The trust chain would be broken when the compromised KSK
   is removed from the child's zone while the parent still has a DS
   pointing to the compromised KSK (the assumption is that there is only
   one DS at the parent.  If there are multiple DSs this does not apply
   -- however the chain of trust of this particular key is broken).

   Note that an attacker's zone still uses the compromised KSK and the



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


   presence of a parental DS would cause the data in this zone to appear
   as valid.  Removing the compromised key would cause the attacker's
   zone to appear as valid and the child's zone as Bogus.  Therefore we
   advise not to remove the KSK before the parent has a DS to a new KSK
   in place.

4.3.1.1.  Keeping the Chain of Trust Intact

   If we follow this advice the timing of the replacement of the KSK is
   somewhat critical.  The goal is to remove the compromised KSK as soon
   as the new DS RR is available at the parent.  And also make sure that
   the signature made with a new KSK over the key set with the
   compromised KSK in it expires just after the new DS appears at the
   parent.  Thus removing the old cruft in one swoop.

   The procedure is as follows:
   1.  Introduce a new KSK into the key set, keep the compromised KSK in
       the key set.
   2.  Sign the key set, with a short validity period.  The validity
       period should expire shortly after the DS is expected to appear
       in the parent and the old DSs have expired from caches.
   3.  Upload the DS for this new key to the parent.
   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
       to appear in the authoritative servers and then wait as long as
       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
       and modify/extend the expiration time.
   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
       key set using your "normal" validity interval.

   An additional danger of a key compromise is that the compromised key
   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
   nameserver changes at the parent.  When that happens the domain may
   be in dispute.  An authenticated out-of-band and secure notify
   mechanism to contact a parent is needed in this case.

   Note that this is only a problem when the DNSKEY and or DS records
   are used for authentication at the parent.

4.3.1.2.  Breaking the Chain of Trust

   There are two methods to break the chain of trust.  The first method
   causes the child zone to appear as 'Bogus' to validating resolvers.
   The other causes the the child zone to appear as 'insecure'.  These
   are described below.

   In the method that causes the child zone to appear as 'Bogus' to
   validating resolvers, the child zone replaces the current KSK with a
   new one and resigns the key set.  Next it sends the DS of the new key



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


   to the parent.  Only after the parent has placed the new DS in the
   zone, the child's chain of trust is repaired.

   An alternative method of breaking the chain of trust is by removing
   the DS RRs from the parent zone altogether.  As a result the child
   zone would become insecure.

4.3.2.  ZSK Compromise

   Primarily because there is no parental interaction required when a
   ZSK is compromised, the situation is less severe than with a KSK
   compromise.  The zone must still be re-signed with a new ZSK as soon
   as possible.  As this is a local operation and requires no
   communication between the parent and child this can be achieved
   fairly quickly.  However, one has to take into account that just as
   with a normal rollover the immediate disappearance of the old
   compromised key may lead to verification problems.  Also note that as
   long as the RRSIG over the compromised ZSK is not expired the zone
   may be still at risk.

4.3.3.  Compromises of Keys Anchored in Resolvers

   A key can also be pre-configured in resolvers.  For instance, if
   DNSSEC is successfully deployed the root key may be pre-configured in
   most security aware resolvers.

   If trust-anchor keys are compromised, the resolvers using these keys
   should be notified of this fact.  Zone administrators may consider
   setting up a mailing list to communicate the fact that a SEP key is
   about to be rolled over.  This communication will of course need to
   be authenticated e.g. by using digital signatures.

   End-users faced with the task of updating an anchored key should
   always validate the new key.  New keys should be authenticated out-
   of-band, for example, looking them up on an SSL secured announcement
   website.

4.4.  Parental Policies

4.4.1.  Initial Key Exchanges and Parental Policies Considerations

   The initial key exchange is always subject to the policies set by the
   parent.  When designing a key exchange policy one should take into
   account that the authentication and authorization mechanisms used
   during a key exchange should be as strong as the authentication and
   authorization mechanisms used for the exchange of delegation
   information between parent and child.  I.e. there is no implicit need
   in DNSSEC to make the authentication process stronger than it was in



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


   DNS.

   Using the DNS itself as the source for the actual DNSKEY material,
   with an out-of-band check on the validity of the DNSKEY, has the
   benefit that it reduces the chances of user error.  A DNSKEY query
   tool can make use of the SEP bit [3] to select the proper key from a
   DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
   sent.  It can validate the self-signature over a key; thereby
   verifying the ownership of the private key material.  Fetching the
   DNSKEY from the DNS ensures that the chain of trust remains intact
   once the parent publishes the DS RR indicating the child is secure.

   Note: the out-of-band verification is still needed when the key-
   material is fetched via the DNS.  The parent can never be sure
   whether the DNSKEY RRs have been spoofed or not.

4.4.2.  Storing Keys or Hashes?

   When designing a registry system one should consider which of the
   DNSKEYs and/or the corresponding DSs to store.  Since a child zone
   might wish to have a DS published using a message digest algorithm
   not yet understood by the registry, the registry can't count on being
   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
   that registry systems at least support storing DS records.

   It may also be useful to store DNSKEYs, since having them may help
   during troubleshooting and, as long as the child's chosen message
   digest is supported, the overhead of generating DS records from them
   is minimal.  Having an out-of-band mechanism, such as a registry
   directory (e.g.  Whois), to find out which keys are used to generate
   DS Resource Records for specific owners and/or zones may also help
   with troubleshooting.

   The storage considerations also relate to the design of the customer
   interface and the method by which data is transferred between
   registrant and registry; Will the child zone administrator be able to
   upload DS RRs with unknown hash algorithms or does the interface only
   allow DNSKEYs?  In the registry-registrar model one can use the
   DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
   and optionally DNSKEY RRs.

4.4.3.  Security Lameness

   Security Lameness is defined as what happens when a parent has a DS
   RR pointing to a non-existing DNSKEY RR.  When this happens the
   child's zone may be marked as "Bogus" by verifying DNS clients.

   As part of a comprehensive delegation check the parent could, at key



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


   exchange time, verify that the child's key is actually configured in
   the DNS.  However if a parent does not understand the hashing
   algorithm used by child the parental checks are limited to only
   comparing the key id.

   Child zones should be very careful removing DNSKEY material,
   specifically SEP keys, for which a DS RR exists.

   Once a zone is "security lame", a fix (e.g. removing a DS RR) will
   take time to propagate through the DNS.

4.4.4.  DS Signature Validity Period

   Since the DS can be replayed as long as it has a valid signature, a
   short signature validity period over the DS minimizes the time a
   child is vulnerable in the case of a compromise of the child's
   KSK(s).  A signature validity period that is too short introduces the
   possibility that a zone is marked Bogus in case of a configuration
   error in the signer.  There may not be enough time to fix the
   problems before signatures expire.  Something as mundane as operator
   unavailability during weekends shows the need for DS signature
   validity periods longer than 2 days.  We recommend an absolute
   minimum for a DS signature validity period of a few days.

   The maximum signature validity period of the DS record depends on how
   long child zones are willing to be vulnerable after a key compromise.
   On the other hand shortening the DS signature validity interval
   increases the operational risk for the parent.  Therefore the parent
   may have policy to use a signature validity interval that is
   considerably longer than the child would hope for.

   A compromise between the operational constraints of the parent and
   minimizing damage for the child may result in a DS signature validity
   period somewhere between the order of a week to order of months.

   In addition to the signature validity period, which sets a lower
   bound on the number of times the zone owner will need to sign the
   zone data and which sets an upper bound to the time a child is
   vulnerable after key compromise, there is the TTL value on the DS
   RRs.  Shortening the TTL means that the authoritative servers will
   see more queries.  But on the other hand, a short TTL lowers the
   persistence of DS RRSets in caches thereby increases the speed with
   which updated DS RRSets propagate through the DNS.


5.  IANA Considerations

   This overview document introduces no new IANA considerations.



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


6.  Security Considerations

   DNSSEC adds data integrity to the DNS.  This document tries to assess
   the operational considerations to maintain a stable and secure DNSSEC
   service.  Not taking into account the 'data propagation' properties
   in the DNS will cause validation failures and may make secured zones
   unavailable to security aware resolvers.


7.  Acknowledgments

   Most of the ideas in this draft were the result of collective efforts
   during workshops, discussions and try outs.

   At the risk of forgetting individuals who were the original
   contributors of the ideas we would like to acknowledge people who
   were actively involved in the compilation of this document.  In
   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.

   Some material in this document has been copied from RFC 2541 [12].

   Mike StJohns designed the key exchange between parent and child
   mentioned in the last paragraph of Section 4.2.2

   Section 4.2.4 was supplied by G. Guette and O. Courtay.

   Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
   the spelling and style issues.

   Kolkman and Gieben take the blame for introducing all miscakes(SIC).

   Kolkman was employed by the RIPE NCC while working on this document.


8.  References

8.1.  Normative References

   [1]  Mockapetris, P., "Domain names - concepts and facilities",
        STD 13, RFC 1034, November 1987.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain