[dns-operations] NSEC3PARAM iteration count update

[Olafur Gudmundsson]

On Monday, 8 January, 2018 02:15, "Viktor Dukhovni" <ietf-dane at dukhovni.org> said:



> 
> 
> > On Jan 8, 2018, at 1:05 AM, Lanlan Pan <abbypan at gmail.com> wrote:
> >
> >> The salt value and iteration counts above 0 (i.e. 1 as you note below)
> >> turned out to be largely counter-productive. It seems that Verisign,
> >> for example, understand this quite clearly. The ".com" zone has an
> >> empty salt, 0 iterations, but uses opt-out:
> >>
> >> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. NSEC3 1 1 0 -
> CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
> >
> > "empty salt, 0 iteration" will be close to NSEC , just a simple hash map.
> 
> Actually, no, because the input to the hash is the FQDN, so the same
> label hashes differently in each domain. The salt adds little value
> unless rotated frequently, and rotation is both difficult and rare
> in practice. See
> 
> https://tools.ietf.org/html/rfc5155#section-5
> 
> Then the calculated hash of an owner name is
> 
> IH(salt, owner name, iterations),
> 
> where the owner name is in the canonical form, defined as:
> 
> The wire format of the owner name where:
> 
> 1. The owner name is fully expanded (no DNS name compression) and
> fully qualified;
> 
> With or without the salt, any rainbow tables are per-domain. If the
> attacker skips pre-computation, and just computes fresh target-specific
> hashes from a suitable dictionary, the salt offers no protection.
> 
> And yes, I am basically suggesting simplifying NSEC3 to "slightly obfuscated
> NSEC with opt-out" (perhaps just one hash operation). This is sufficient to
> deter "casual" zone-walking. A determined adversary will learn most names in
> most domains. They'll be found in certificates, in PTR records, dictionary
> attacks, ...
> 
 
+100 
The value of opt-out is only for Delegation-mainly/only zones 
NSEC3 leaks the size of the zone for medium to large zones in no time. 
NSEC3 is of no value for "small" zones as most names are obvious 
 
Olafur
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180109/0c0d3351/attachment.html>