NSEC3 Params

Peter Koch pk at DENIC.DE
Mon Mar 6 15:40:15 CET 2017


On Mon, Mar 06, 2017 at 09:20:09AM -0500, Viktor Dukhovni wrote:
> 
> > On Mar 6, 2017, at 4:39 AM, Andreas Schulze <andreas.schulze at datev.de> wrote:
> > 
> > Hello Viktor,
> > 
> > Your suggestion differ from RFC 5155.
> > https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing"
> > 
> > Could you explain your choice more verbose?
> 
> If you do manual full-zone re-signing, feel free.  Most zones
> are re-signed incrementally and automatically, but the entire
> NSEC3 chain must use a single salt (or two chains need to be
> built during the transition).

see also section 5.3.3 of RFC 6781, but take it with, well, a grain
of salt.

> In any case, the main benefit of NSEC3 is "opt-out" to allow
> sparse signing in TLDs, hiding the zone content is only an
> emotional impulse, there's little rational use for it in the
> vast majority of cases.

In the context of (future) DANE applications, enumeration resistance
might become more critical even for those cases.
The point probably is that if you chose a salt - rather than indeed
applying NSEC3 for opt-out only - then you might want to change that,
occasionally.

-Peter


More information about the dane-users mailing list