changing NSEC3 salt

[Chris Thompson]

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


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

-- 
Chris Thompson
Email: cet1 at cam.ac.uk