draft-ietf-dnsext-nsec3-02.txt

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

   a single record can, by chance, prove more than one of these facts.

   When a verifier checks this response, then the existence of



Laurie, et al.          Expires December 3, 2005               [Page 12]

Internet-Draft                    nsec3                        june 2005


   beta.example together with the non-existence of alfa.beta.example
   proves that the closest encloser is indeed beta.example.  The non-
   existence of *.beta.example shows that there is no wildcard at the
   closest encloser, and so no source of synthesis for
   omega.alfa.beta.example.  These two facts are sufficient to satisfy
   the resolver that the QNAME cannot be resolved.

   In practice, since the NSEC3 owner and next names are hashed, if the
   server responds with an NSEC3 for beta.example, the resolver will
   have to try successively longer names, starting with example, moving
   to beta.example, alfa.beta.example, and so on, until one of them
   hashes to a value that matches the interval (but not the ownername
   nor next owner name) of one of the returned NSEC3s (this name will be
   alfa.beta.example).  Once it has done this, it knows the closest
   encloser (i.e. beta.example), and can then easily check the other two
   required proofs.

   Note that it is not possible for one of the shorter names tried by
   the resolver to be denied by one of the returned NSEC3s, since, by
   definition, all these names exist and so cannot appear within the
   range covered by an NSEC3.  Note, however, that the first name that
   the resolver tries MUST be the apex of the zone, since names above
   the apex could be denied by one of the returned NSEC3s.

6.3  Salting

   Augmenting original ownernames with salt before hashing increases the
   cost of a dictionary of pre-generated hash-values.  For every bit of
   salt, the cost of the dictionary doubles.  The NSEC3 RR can use a
   maximum of 2040 bits of salt, multiplying the cost by 2^2040.

   There MUST be a complete set of NSEC3s for the zone using the same
   salt value.  The salt value for each NSEC3 RR MUST be equal for a
   single version of the zone.

   The salt SHOULD be changed every time the zone is resigned to prevent
   precomputation using a single salt.

6.4  Hash Collision

   Hash collisions occur when different messages have the same hash
   value.  The expected number of domain names needed to give a 1 in 2
   chance of a single collision is about 2^(n/2) for a hash of length n
   bits (i.e. 2^80 for SHA-1).  Though this probability is extremely
   low, the following paragraphs deal with avoiding collisions and
   assessing possible damage in the event of an attack using hash
   collisions.




Laurie, et al.          Expires December 3, 2005               [Page 13]

Internet-Draft                    nsec3                        june 2005


6.4.1  Avoiding Hash Collisions during generation

   During generation of NSEC3 RRs, hash values are supposedly unique.
   In the (academic) case of a collision occurring, an alternative salt
   SHOULD be chosen and all hash values SHOULD be regenerated.

   If hash values are not regenerated on collision, the NSEC3 RR MUST
   list all authoritative RR types that exist for both owners, to avoid
   a replay attack, spoofing an existing type as non-existent.

6.4.2  Second Preimage Requirement Analysis

   A cryptographic hash function has a second-preimage resistance
   property.  The second-preimage resistance property means that it is
   computationally infeasible to find another message with the same hash
   value as a given message, i.e. given preimage X, to find a second
   preimage X' <> X such that hash(X) = hash(X').  The work factor for
   finding a second preimage is of the order of 2^160 for SHA-1.  To
   mount an attack using an existing NSEC3 RR, an adversary needs to
   find a second preimage.

   Assuming an adversary is capable of mounting such an extreme attack,
   the actual damage is that a response message can be generated which
   claims that a certain QNAME (i.e. the second pre-image) does exist,
   while in reality QNAME does not exist (a false positive), which will
   either cause a security aware resolver to re-query for the non-
   existent name, or to fail the initial query.  Note that the adversary
   can't mount this attack on an existing name but only on a name that
   the adversary can't choose and does not yet exist.

6.4.3  Possible Hash Value Truncation Method

   The previous sections outlined the low probability and low impact of
   a second-preimage attack.  When impact and probability are low, while
   space in a DNS message is costly, truncation is tempting.  Truncation
   might be considered to allow for shorter ownernames and rdata for
   hashed labels.  In general, if a cryptographic hash is truncated to n
   bits, then the expected number of domains required to give a 1 in 2
   probability of a single collision is approximately 2^(n/2) and the
   work factor to produce a second preimage resistance is 2^n.

   An extreme hash value truncation would be truncating to the shortest
   possible unique label value.  Considering that hash values are
   presented in base32, which represents 5 bits per label character,
   truncation must be done on a 5 bit boundary.  This would be unwise,
   since the work factor to produce collisions would then approximate
   the size of the zone.




Laurie, et al.          Expires December 3, 2005               [Page 14]

Internet-Draft                    nsec3                        june 2005


   Though the mentioned truncation can be maximized to a certain
   extreme, the probability of collision increases exponentially for
   every truncated bit.  Given the low impact of hash value collisions
   and limited space in DNS messages, the balance between truncation
   profit and collision damage may be determined by local policy.  Of
   course, the size of the corresponding RRSIG RR is not reduced, so
   truncation is of limited benefit.

   Truncation could be signalled simply by reducing the length of the
   first label in the ownername.  Note that there would have to be a
   corresponding reduction in the length of the Next Hashed Ownername
   field.

7.  Performance Considerations

   Iterated hashes will obviously impose a performance penalty on both
   authoritative servers and resolvers.  Therefore, the number of
   iterations should be carefully chosen.  In particular it should be
   noted that a high value for iterations gives an attacker a very good
   denial of service attack, since the attacker need not bother to
   verify the results of their queries, and hence has no performance
   penalty of his own.

   On the other hand, nameservers with low query rates and limited
   bandwidth are already subject to a bandwidth based denial of service
   attack, since responses are typically an order of magnitude larger
   than queries, and hence these servers may choose a high value of
   iterations in order to increase the difficulty of offline attempts to
   enumerate their namespace without significantly increasing their
   vulnerability to denial of service attacks.

8.  IANA Considerations

   IANA has to create a new registry for NSEC3 Hash Functions.  The
   range for this registry is 0-127.  Value 0 is the identity function.
   Value 1 is SHA-1.  Values 2-126 are Reserved For Future Use. Value
   127 is marked as Experimental.

9.  Security Considerations

   The NSEC3 records are still susceptible to dictionary attacks (i.e.
   the attacker retrieves all the NSEC3 records, then calculates the
   hashes of all likely domain names, comparing against the hashes found
   in the NSEC3 records, and thus enumerating the zone).  These are
   substantially more expensive than traversing the original NSEC
   records would have been, and in any case, such an attack could also
   be used directly against the name server itself by performing queries
   for all likely names, though this would obviously be more detectable.



Laurie, et al.          Expires December 3, 2005               [Page 15]

Internet-Draft                    nsec3                        june 2005


   The expense of this off-line attack can be chosen by setting the
   number of iterations in the NSEC3 RR.

   High-value domains are also susceptible to a precalculated dictionary
   attack - that is, a list of hashes for all likely names is computed
   once, then NSEC3 is scanned periodically and compared against the
   precomputed hashes.  This attack is prevented by changing the salt on
   a regular basis.

   Walking the NSEC3 RRs will reveal the total number of records in the
   zone, and also what types they are.  This could be mitigated by
   adding dummy entries, but certainly an upper limit can always be
   found.

   Hash collisions may occur.  If they do, it will be impossible to
   prove the non-existence of the colliding domain - however, this is
   fantastically unlikely, and, in any case, DNSSEC already relies on
   SHA-1 to not collide.

10.  References

10.1  Normative References

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

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC2929]  Eastlake, D., Brunner-Williams, E., and B. Manning,
              "Domain Name System (DNS) IANA Considerations", BCP 42,
              RFC 2929, September 2000.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, September 2003.



Laurie, et al.          Expires December 3, 2005               [Page 16]

Internet-Draft                    nsec3                        june 2005


   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

10.2  Informative References

   [I-D.ietf-dnsext-trustupdate-threshold]
              Ihren, J., "An In-Band Rollover Mechanism and an Out-Of-
              Band Priming Method for DNSSEC  Trust Anchors.",
              draft-ietf-dnsext-trustupdate-threshold-00 (work in
              progress), October 2004.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.


Authors' Addresses

   Ben Laurie
   Nominet
   17 Perryn Road
   London  W3 7LR
   England

   Phone: [phone]
   Email: [e-mail]


   Geoffrey Sisson
   Nominet










Laurie, et al.          Expires December 3, 2005               [Page 17]

Internet-Draft                    nsec3                        june 2005


   Roy Arends
   Telematica Instituut
   Brouwerijstraat 1
   7523 XC  Enschede
   The Netherlands

   Phone: [phone]
   Email: [e-mail]

Appendix A.  Example Zone

   This is a zone showing its NSEC3 records.  They can also be used as
   test vectors for the hash algorithm.


   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1
                              3600
                              300
                              3600000
                              3600 )
                  3600 RRSIG  SOA 5 1 3600 20050712112304 (
                              20050612112304 62699 example.
                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
                              qYIt90txzE/4+g== )
                  3600 NS     ns1.example.
                  3600 NS     ns2.example.
                  3600 RRSIG  NS 5 1 3600 20050712112304 (
                              20050612112304 62699 example.
                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
                              1SH5r/wfjuCg+g== )
                  3600 MX     1 xx.example.
                  3600 RRSIG  MX 5 1 3600 20050712112304 (
                              20050612112304 62699 example.
                              L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
                              NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
                              S/o/g5C8VM6ftQ== )
                  3600 DNSKEY 257 3 5 (
                              AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX