changing NSEC3 salt

[David Newman]

On 2/11/14 7:38 AM, Chris Thompson wrote:
> On Feb 10 2014, Mark Andrews wrote:
> 
>> In message <52F94EE2.7080505 at ksu.edu>, "Lawrence K. Chen, P.Eng." writes:
> [... snip ...]
>>> On 02/06/14 15:07, Timothe Litt wrote:
> [... snip ...]
>>> > Note also the RFC 5155 recommendation:
>>> >> The salt SHOULD be at least 64 bits long and unpredictable, so that
>>> >> an attacker cannot anticipate the value of the salt and compute the
>>> >> next set of dictionaries before the zone is published.
>>> > In case it wasn't obvious, I should have noted that the length
>>> would be
>>> > a config file entry.
> [...]
>>>
>>> Interesting....I guess I need to keep up more on these things.
>>>
>>> I haven't changed my NSEC3 salt since I initially set up DNSSEC here,
>>> and seemed to me that the document I was working off of back then said 4
>>> hex characters.
>>>
>>> Which probably made it extra hard for me to come up with a random
>>> number.  So, its totally non-random...so all I did was take the hex for
>>> two (well-known) letters...for my salt.  Since the salt is 'public',
>>> I'll say it.  my salt is "KS", or "4b53".
>>>
>>> So now to think of how to add NSEC3 salt changing to my current
>>> automation scripts....
>>
>> And for most zones it won't make a bit of difference.  Most are
>> mainly static and once you have sampled the zone enough times to
>> have (almost) all the NSEC3 records you just keep testing against
>> those NSEC3 records.  Once you find a name in the zone you can just
>> test that it still exists.  When the NSEC3 parameters change you
>> just run the know names through for a non-existing type and you
>> get confirmation of the name and a new set of NSEC3 records without
>> having to do as much sampling.
>>
>> It makes a bit of sense for zones that have names that a coming and
>> going all the time but even then you can reuse existing knowledge.
> 
> It's probably worth noticing what the big operators do, e.g.
> 
> $ dig +noall +answer +nottl NSEC3PARAM com. edu. net. org.
> com.                    IN      NSEC3PARAM 1 0 0 -
> edu.                    IN      NSEC3PARAM 1 0 0 -
> net.                    IN      NSEC3PARAM 1 0 0 -
> org.                    IN      NSEC3PARAM 1 0 1 D399EAAB
> 
> (AFAIK the salt used for "org" has never changed - and the same value
> is used for 23 other TLDs.) A quick check revealed 216 TLDs [*] with
> NSEC3PARAM records, distributed as follows:
> 
>   Extra                 Salt length (bytes)               Total
> iterations    0    2    3    4    5    6    8   10   16
> 
>     0         7    -    -    -    -    -    -    -    -       7
>     1         -    -    -  125    -    -    1    -    -     126
>     2         -    -    -    2    -    -    -    -    1       3
>     3         -    3    -    1    -    -    -    -    -       4
>     5         1    -    -    1    5    -   15    1    -      23
>     8         -    -    -    -    -    2    -    -    -       2
>    10         2    4    5   25    -    -    1    -    -      37
>    12         -    -    -    -    -    -    5    1    -       6
>    13         -    -    1    -    -    -    -    -    -       1
>    15         -    -    -    1    -    -    -    -    -       1
>    17         -    -    -    -    -    -    1    -    -       1
>    25         -    -    -    -    -    -    2    -    -       2
>   100         -    -    -    -    -    -    1    -    -       1
>   150         -    -    -    1    -    -    1    -    -       2
> 
>  Total       10    7    6  156    5    2   27    2    1     216


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

dn



> 
> 
> [*] A lot more than there used to be, due to the influx of new gTLDs.
>