KSK signing all records; NSEC3 algorithm status?

Wed May 28 03:02:26 UTC 2014

In message <20140528012734.GA55903 at redoubt.spodhuis.org>, Phil Pennock writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 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.

>  My first rollover, though.
> I've ended up with all records being signed by the new KSK, apparently
> through an algorithm mismatch, and I'm not seeing how to handle this --
> I'm wondering if I've run into a current Bind limitation?
> 
> I'm using Bind 9.10, and the zone statement includes:
> 
>     auto-dnssec maintain;
>     inline-signing yes;
> 
> I had originally set up the signing for the zone with:
> 
>     rndc signing -nsec3param 1 0 100 $(openssl rand -hex 8) $zone
> 
> For this rollover, I generated a new key, and perhaps stupidly took the
> opportunity to bump the hash algorithm:
> 
>     dnssec-keygen -3 -a RSASHA256 -b 2048 -f KSK xn--qck5b9a5eml3bze.jp

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.

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.

> and deployed to the host; while checking man-pages to figure out how to
> tell Bind to start using the new key, I noticed that it had in fact
> picked it up.  ZSK being signed with both old and new KSK -- fantastic!
> Alas: <http://dnsviz.net/d/xn--qck5b9a5eml3bze.jp/dnssec/>
> Which shows the id=53065 SEP-flagged KSK being used to sign non-DNSKEY
> records within the zone.
> 
> List archives led me to Kyle Brantley's post:
>   Subject: Re: auto-dnssec maintain: KSK being used as a ZSK as well?
>   Date: Fri, 21 Dec 2012 19:50:43 -0700
>   Message-ID: <50D52003.4010508 at averageurl.com>
> which clued me in with:
> } Aye. Thanks, Alan, for the help. The problem was that I was generating a
> } RSASHA512 for my KSK, but I was using NSEC3RSASHA1 for my ZSKs. I generated
>  a
> } temporary ZSK that was also RSASHA512 to match my KSK and it is working gre
> at
> } now.
> 
> The rndc manual page states:
> - ----------------------------8< cut here >8------------------------------
>            rndc signing -nsec3param sets the NSEC3 parameters for a zone. Thi
> s
>            is the only supported mechanism for using NSEC3 with inline-signin
> g
>            zones. Parameters are specified in the same format as an NSEC3PARA
> M
>            resource record: hash algorithm, flags, iterations, and salt, in
>            that order.
> 
>            Currently, the only defined value for hash algorithm is 1,
>            representing SHA-1. The flags may be set to 0 or 1, depending on
>            whether you wish to set the opt-out bit in the NSEC3 chain.
>            iterations defines the number of additional times to apply the
>            algorithm when generating an NSEC3 hash. The salt is a string of
>            data expressed in hexadecimal, a hyphen (`-') if no salt is to be
>            used, or the keyword auto, which causes named to generate a random
>            64-bit salt.
> - ----------------------------8< cut here >8------------------------------
> 
> I do not really want to move away from inline-signing/maintain -- it's a
> great feature which automates something which should be automated.  I
> know that in theory, there's nothing requiring the KSK/ZSK split but I'd
> still like to get back to a more traditional setup.
> 
>  (1) Have I put myself into a bad situation where my only way out is to
>      generate a new DNSKEY KSK, this time back with the default SHA1,
>      add it to the zone, then get the registrar to update the DS
>      records?
> 
>  (2) Is it the case that the problem is that given a hash algorithm X
>      and a second algorithm Y, with X used for the KSK and Y used for
>      the ZSK, if inline-signing sees such a situation with no ZSK using
>      algorithm X, then it will sign the entire zone with the KSK, as
>      suggested by Kyle's debugging in 2012?  Is this intentional?

	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.

>      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.

	DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3
	capable.  All future algorithms are supposed to be NSEC3
	capable.

	For DNSKEY algorithms 252, 253 and 254 you need to look at
	the individual algorithms encoded at the start of the key
	field.

	Algorithms 1, 3, and 5 are not NSEC3 capable and their
	presence in the DNSKEY RRset will stop attempts to use NSEC3
	with the zone.

>  (3) Anyone have any constructive suggestions or advice to guide me out?
>      Even if it's just "go route 1, at this time don't bother touching
>      other hash algorithms while using NSEC3"?
> 
> Guidance appreciated, thanks,
> - -Phil
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBCAAGBQJThTt4AAoJEKBsj+IM0duFFq4IAJ+dn1+0Vkm7XnN+r70QDWmD
> fgEN0G9D72TRJ0lYqkd19W/qwctfKDkCUaTt3BIjRwBDV3bQXxqLQkXxH7jWFNXK
> czZEEm6mOKCQWcBEKAMtfWM5cGKGAjSjfvbA2ZOAvuUIkDfYN0s4kcWYFTre7Zyk
> SSnZi909xs1ZPiuz447dmUBr3gg5wNJAuUNiNJJP9DHriu6542DdRzUtbu3zmABG
> rBAjS/budz/nr3INHYvTCyR1PJ7RtzxtVT5PcnQ0GnP1H92Zspk3rDrqc8CWDSUA
> 5UUV0D8qSE8xvzwcW6qiaJO7OkYoaUgxjgsS0rsceOoLWLriIZuVsV8NgT8SNMw=
> =hRKl
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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