[dns-operations] NSEC3PARAM iteration count update

[Lanlan Pan]

Viktor Dukhovni <ietf-dane at dukhovni.org>于2018年1月8日周一 下午3:20写道：

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

The salt adds little value unless rotated frequently, and rotation is both
difficult and rare in practice.  ＋1
Salt is public, not secret, hence, little protection.

When we update ZSK/KSK, salt and rotation can be updated together to
reshuffle the subdomain arrangement.
One hash operation is a static subdomain arrangement.


> 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, ...
>

Agree.


> --
>         Viktor.
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180109/9fd24200/attachment.html>