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