shared KSK for static zone and dynamic subzone?

[Mark Andrews]

In message <4DB7B21D.8010503 at data.pl>, Torinthiel writes:
> On 04/27/11 05:40, /dev/rob0 wrote:
> > On Tue, Apr 26, 2011 at 10:15:18AM +0100, Phil Mayers wrote:
> >> On 04/26/2011 02:13 AM, /dev/rob0 wrote:
> >>> Is there any
> >>> reason why I can't use the parent zone's KSK for the dynamic
> >>> zone? Better yet, is there a reason why I shouldn't?
> >>
> >> Better yet, why *would* you? Keys aren't exactly expensive to=20
> >> generate.
> >=20
> > Again, the $SUBJECT problem is resolved, but I have come upon a=20
> > possible reason to reuse a key.
> >=20
> > I'm setting up a private namespace (RFC 1918 networks and imaginary=20
> > domain names) named+dhcpd system with three static zones, a dynamic=20
> > forward zone, and two dynamic reverse zones. Six total.
> >=20
> > I want all these zones to be signed. Why? No good reason, just a
> > learning exercise, actually. "Because I can."
> 
> That's a very good reason.
> 
> 
> > [...]
> >
> > So that's what I'm going to do. Two more zones, four more keys, but=20
> > only two in trusted-keys. Tolerable.
> 
> You have some other options as well. First, as you've noticed, only the
> top zone in the chain needs to have keys configured, all zones below can
> benefit from DS records.
> Second, if your zones are public, you can add your key to dlv.isc.org,
> and only have to configure one key (which is build in into bind BTW).
> 
> Third, you can create your own DLV, and still use one key even with
> private zones. Downside is that BIND cannot use two DLV repositories, so
> you won't benefit from a lot of DLV configured zones. And I don't know
> of a sensible way to duplicate ISC DLV and add some more keys.
> 
> You could download zones from http://secspider.cs.ucla.edu/ add your own
> keys and sign by your own key. But keep in mind, that while ISC DLV asks
> admins to configure their zones and verifies that they have keys and
> abilities to modify zone, secspider simply walks everything (but from
> several points around the world), so it's probably less secure.
> 
> 
> >=20
> >> Anyway, the answer is "not really". The keys that bind generates
> >> include the zone name, and you can't easily use a key whose name
> >> !=3D zone, and certainly not whose name is in a different zone.
> >>
> >> You're just complicating your life to no benefit. Use a different=20
> >> key for the child.
> >=20
> > I'm a bit late to the DNSSEC party, what with the signed root being=20
> > in place already, but ISTM that these trusted-keys could be a major=20
> > management problem. Am I wrong? Is it still a problem?
> 
> Yes, but there are several possibilities to solve it.
> First note that root is already signed, but not all (not even most) TLDs
> are signed/accept DS records for delegations. So eg in .pl you are no
> better than if root was not signed.
> 
> Ways to circumvent this include:
> 1) have your key distributed widely. Worst IMHO option, as it requires a
> good distribution chain both at start, and when you change your KSK.
> 
> 2) DLV - from DNS point of view it's a simple zone with a bit different
> record types. If you have dlv.net, and want to check if example.com is
> correclty signed, than your resolver asks for example.com.dlv.net, of
> type DLV and if it receives correct answer (this implies that first you
> trust DLV's key) it behaves just as if it got example.com's DS record
> from .com. You still have to maintain key, but only one.
> 
> 3) RFC 5011 specifies how keys can authenticate themselves, thus
> simplifying KSK rollover.
> 
> Torinthiel

There is zero point in trying to share keying material between zones
unless you have a HSM and it has limits on the number of keys it
supports.  The RRSIGs differ.  The DS differ.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org