On Feb 23, 2010, at 8:20 AM, Florian Weimer wrote:
> * 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."
>
ACK
> (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.
Isn't that only the case for QTYPE=ANY? Or when the server at the
authoritative side is broken?
For both cases I do not think that this is a strong consideration.
Also, but orthogonal,
At Labs we are about to measure the impact of the amount of NSEC3 iterations on
a recursive nameserver. Maybe there are some additional considerations that
flow from that, will keep you all posted.
--Olaf
________________________________________________________
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
