Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Florian Weimer <[e-mail]>]

* Olaf Kolkman:

> 5.3.3.  NSEC3 Salt
>
>    The salt with NSEC3 is not used to increase the work required by an
>    attacker attacking multiple domains, but as a method to enable
>    creating a new set of hash values if at some point that might be
>    required.  The salt is used as a "roll over".  The FQDN RRlabel,
>    which is part of the value that is hashed, already ensures that brute
>    force work for one RRlabel can not be re-used to attack other RRlabel
>    due to their uniquenes.
>
>    Key rollovers limit the amount of time attackers can spend on
>    attacking a certain key before it is retired.  The salt serves the
>    same purpose for the hashes, which are independant of the key being
>
>
>
> Kolkman & Gieben        Expires September 8, 2009              [Page 33]
> Internet-Draft   DNSSEC Operational Practices, Version 2      March 2009
>
>
>    used, and therefor do not change when rolling over a key.  Changing
>    the salt would cause an attacker to lose all precalculated work for
>    that zone.
>
>    The salt of all NSEC3 records in a zone needs to be the same.  Since
>    changing the salt requires the NSEC3 records to be regenerated, and
>    thus requires generating new RRSIG's over these NSEC3 records, it is
>    recommended to only change the salt when changing the Zone Signing
>    Key, as that process in itself already requires all RRSIG's to be
>    regenerated.

"However, unlike Zone Signing Key changes, NSEC3 salt changes do not
need special rollover procedures.  It is possible to change the salt
each time the zone is updated."

(Assuming that this is true, which I think it is.)

Perhaps the following is helpful as well?

5.3.5 Response size considerations

NSEC3 records are larger than NSEC records because of the embedded
hashes.  However, NSEC records are sometimes returned in response to
DO=0 queries, pushing the response over the 512 byte limit and causing
TCP fallback (or worse).  This does not happen with NSEC3 records
because their owner name does not normally match the queried name.
Therefore, NSEC3 records provide better insulation of child zones from
the DNSSEC deployment in the parent zone.

-- 
Florian Weimer                <[e-mail]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]