--On 22 February 2010 14:41:19 +0100 "W.C.A. Wijngaards" <[email protected]> wrote:
I am not saying this makes NSEC3 a unchoosable option; but it is a tradeoff, and if you can use NSEC because you do not need the benefits of NSEC3, you should, because it'll drive down bandwidth and cpu usage (slightly) for everyone.
Using NSEC instead of NSEC3 for the above reasons seems sensible. Using NSEC instead of NSEC3 also seems sensible if you don't need NSEC3 features for reasons like ease of debugging (as the zone file is more readable) and fear of implementation bugs from increased complexity also seems reasonable. Using NSEC instead of NSEC3 because you fear SHA1 collisions does not seem sensible, as if you fear SHA1 collisions, you have other more significant problems with DNSSEC to worry about, and thus this is not, in my opinion, reasonable. And it isn't sensible to suggest users worry about it. If we are going to mention it, it should be in security considerations, saying NSEC3 is dependent upon certain properties of its hash algorithm (I forget now whether it is collision resistance, pre-image resistance or or what), but this should also point out the whole of DNSSEC is predicated on similar qualities. Note the current draft already recommends NSEC if you don't need NSEC3 (for reasons other than fear of hash collisions). I am entirely happy with that. -- Alex Bligh _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
