On 2/11/14 7:38 AM, Chris Thompson wrote: > On Feb 10 2014, Mark Andrews wrote: > >> In message <[email protected]>, "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. > _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
