changing NSEC3 salt

Doug Barton dougb at dougbarton.us
Wed Feb 12 22:10:49 UTC 2014


On 02/12/2014 05:17 AM, Chris Thompson wrote:
> On Feb 11 2014, David Newman wrote:
>
> [...]
>> That's interesting. It seems to contradict Lucas' advice to "always
>> use '1 0 10' for these [NSEC3] flags, as fewer aren't secure enough
>> and more aren't any more secure."
>
> It's difficult to see how that can make sense. Increasing the number
> of iterations simply gives a linear increase in the computational
> cost of testing names against NSEC3s (and the same factor in the
> overheads in authoritative and validating nameservers, of course).

I can't speak directly for Michael, but I was the "lead technical 
reviewer" for "DNSSEC Mastery," so I can tell you from my perspective 
that the intent was not to provide a thorough treatise on all of the 
possible ramifications of every possible combination of flags. The 
intent was to help people get up and running with DNSSEC; with 
reasonable defaults, and a minimum of fuss.

Personally, I am hard pressed to justify setting iterations at a value 
higher than 10. As many others have pointed out, some quite recently, 
NSEC3 is not going to save you from zone walking by a determined 
"attacker." Changing the salt often'ish will help, as will doing more 
than 1 or 2 iterations. But at the end of the day someone who really 
wants to calculate a rainbow table on your zone can and will do so.

> Moore's law wipes out a factor of 10 before very long ...

Exactly .... which is IMO another reason that values higher than 10 are 
not likely to do anything other than increase the costs on validators, 
and for no good reason.

> It's not often mentioned, incidentally, that using more iterations
> increases the probability of a collision. Of course, it's pretty damn
> small to begin with, so that doesn't really matter. But the
> algorithm, described in RFC 5155 section 5, could have been better
> designed from that point of view.

Honestly that wasn't a factor in my thinking, but it's interesting info 
to store away for future use, thanks. :)

Doug


More information about the bind-users mailing list