KSK signing all records; NSEC3 algorithm status?

[Mark Andrews]

In message <20140528151909.GA66390 at redoubt.spodhuis.org>, Phil Pennock writes:
> On 2014-05-28 at 13:02 +1000, Mark Andrews wrote:
> > In message <20140528012734.GA55903 at redoubt.spodhuis.org>, Phil Pennock writes:
> > > The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC
> > > KSK update; good practice on their part.
> > 
> > For most zones you never need to roll DNSSEC keys.  Even for high
> > value zones where someone would be willing to spend the resources
> > to break the public keys once a decade would be fine.
> > 
> > The only reason higher frequency rollovers to occur is to practice them.
> 
> That was my understanding; however, "TLD registrar establishing a
> mandate" is another good reason.

In general TLD's should butt out of this other than to register DS
records.  No TLD's don't need to see DNSKEY records or generate DS
records.

> > This is not a KSK key rollover in the usual sence of the expression.
> > This is rolling to a new DNSKEY algorithm and you should have
> > generated both a KSK and ZSK for this algorithm.
> > 
> > If you want to finish transitioning to RSASHA256 just generate a
> > zone signing key RSASHA256.  Named will sort things out.  You may
> > end up with 3 sets of signatures for a while.  Don't worry about
> > it.
> > 
> > Once that is done you need to add a DS record for the KSK.  You can also
> > remove the old DS if twelve hours have elasped since you started the process.
> 
> The DS record is already in place for the KSK.
> 
> > After the maxmium of (12 hours (DS ttl), the maximum TTL in the
> > zone (at least 12 hours)) after the DS change to remove the old DS
> > you can tell mark the old keys as inactive and not to be published
> > using dnssec-settime.  All the keys for the algorithm need to stop
> > being used and published at the same time.
> 
> Perfect, thanks for that!
> 
> > 	Yes.  Named enforces the signing rules that every record is
> > 	signed with every algorithm.  When you add a new DNSKEY algorithm
> > 	it will ensure that every RRset gets signed with it.  It does
> > 	this incrementally then updates the private type records to
> > 	say that it has completed the operation so you can then add the
> > 	DS records.  If there isn't a ZSK for that algorithm it will
> > 	use a KSK.
> 
> Ah, I hadn't considered how the KSK/ZSK being an operational distinction
> rather than an algorithm distinction would play into the requirements
> around key consistency -- as far as verifiers are concerned, the
> validation of KSK is not a distinct step and does not introduce a "cut"
> for record signing algorithm requirements.  Thanks.
> 
> > >      I can
> > >      see a rationale -- keep one consistent set of signing algorithms,
> > >      reduce potential for interop tangles.  However, since IANA appears
> > >      to only have SHA-1 registered for NSEC3:
> > >        <http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-
> > > parameters.xhtml>
> > >      this seems to be an unfortunate interplay.
> > 
> > 	That is the NSEC3 HASH algorithm, not the DNSKEY algorithm.
> 
> *blush*  Thank you.
> 
> > 	DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3
> > 	capable.  All future algorithms are supposed to be NSEC3
> > 	capable.
> 
> And of course, this is why I'd chosen to use the "-3" option to
> dnssec-keygen, to ensure I remained NSEC3 capable, but by the end of
> chasing the information paths I was on, I'd forgotten this.
> 
> Okay, I think that I'm on track to recovery.  Thanks.

No problem.  Just remember when you generate the keys in the future
to pick the correct DNSKEY algorithm.

> -Phil
> _______________________________________________
> 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