changing NSEC3 salt

[Mark Andrews]

In message <52F94EE2.7080505 at ksu.edu>, "Lawrence K. Chen, P.Eng." writes:
> 
> 
> On 02/06/14 15:07, Timothe Litt wrote:
> > On 06-Feb-14 09:14, Klaus Darilion wrote:
> >>
> >>
> >> On 06.02.2014 14:58, Cathy Almond wrote:
> >>> On 06/02/2014 12:58, Timothe Litt wrote:
> >>>> On 06-Feb-14 05:56, Cathy Almond wrote:
> >>>>> On 05/02/2014 18:54, David Newman wrote:
> >>>>>> The Michael W. Lucas DNSSEC book recommends changing NSEC3 salt every
> >>>>>> time a zone's ZSK changes.
> >>>>>>
> >>>>>> Is this just a matter of a new 'rndc signing' command, or is some
> >>>>>> action
> >>>>>> needed to remove the old salt?
> >>>>>>
> >>>>>> thanks
> >>>>>>
> >>>>>> dn
> >>>>> rndc signing -nsec3param ...
> >>>>>
> >>>>> I would expect the old NSEC3 chain and old NSEC3PARAM record to be
> >>>>> removed, once the new chain is in place.
> >>>>>
> >>>>> (Similarly, the new NSEC3PARAM record will not appear in the zone
> >>>>> until
> >>>>> the new NSEC3 chain has been completely generated).
> >>>>>
> >>>>> Cathy
> >>>>>
> >>>> This seems silly.  Why should a person have to select a salt at all?
> >>>> It's just a random number, and people are really bad at picking random
> >>>> numbers.  Seems like a miss in 'DNSSEC for humans' :-)
> >>>>
> >>>> There should be a mechanism to tell named to pick a random number and
> >>>> use it for the salt.  (I suggest '*' - '-' already means 'none'.) 
> >>>> named
> >>>> already has to know how to get random numbers, so this should not be
> >>>> difficult.  It should work for records supplied in UPDATE transactions
> >>>> as well as rndc signing.
> >>>>
> >>>> A bit more work to have it function when loaded from a zone file,
> >>>> though
> >>>> that doesn't seem unreasonable.  (E.g. if read from a zone file, pick a
> >>>> salt, treat the record as if loaded with that value, and do all the
> >>>> requisite (re-)signing.)
> >>>>
> >>>> I'm copying bind9-bugs so this doesn't get lost.  Please don't copy
> >>>> that
> >>>> list if you comment on this. (Careful with that 'reply all'!)
> >>>>
> >>>> Timothe Litt
> >>>> ACM Distinguished Engineer
> >>>
> >>> Sounds like a good idea - thanks.
> >>
> >> Indeed. It would also solve the theoretical problem of NSEC3 hash
> >> collisions (see my email from 3. Feb 2014)
> >>
> >> regards
> >> Klaus
> >>
> >>
> > Not quite.  It would enable a solution, but it doesn't solve it unless
> > named also checks for a collision, picking a new salt and re-trying in
> > that case.  That would be a good idea (though creating a test case would
> > be a good student challenge).  [If it isn't tested, it doesn't work...]
> > 
> > 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.
> > 
> > 
> > Timothe Litt
> > ACM Distinguished Engineer
> 
> 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.

Mark

> -- 
> Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
> For: Enterprise Server Technologies (EST) -- & SafeZone Ally
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org