Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Olaf Kolkman <[e-mail]>]

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