[Opendnssec-develop] Creating keys

[Roy Arends]

Rick van Rein wrote on 12/02/2008 01:53:21 PM:

> Hello,
> 
> > >>And again, here I can see a many zones using one private key. [...]
> > >>
> > >If you share keys do you need to coordinate key roll overs? [...]
> > >
> > Yes, all zones that share the same private key will need to roll at 
> > the same time.
> 
> Sharing of key pairs makes bundles of sense to me.
> 
> Using PKCS #11 as a generic HSM interface, will give rise to deployment
> models that use simple USB tokens as a low-cost keystore.  This could be
> used by owners of a few zones, such as the administrator of a company's
> single/few domains.  I suspect many companies will want to be "in 
control"
> of their "vital square on the net", based on such a thrifty setup.
> 
> USB tokens cannot store very many key pairs, think of 10 to get an idea.
> It could become a nuisance to be constrained in the number of zones one
> manages if the token cannot cope, and it will at some point cause a new
> domain number 11 to remain unsigned "for now", however long that lasts.
> Being able to share key pairs among zones would be totally reasonable in
> such situations, in my opinion.
> 
> This is not even counting the fact that we would like to have some room
> to move in a token, for overlapping key validity periods.  It would be
> dead wrong to have to deny a KSK rollover to a signer using a USB-token
> for reasons like a slow parent DS pickup on a previous one.  Or worse,
> to be unable to rollover in case of compromise.  We'll need the space
> for a variable few KSK at the same time in such a token, and that is
> enough demand to roughly fill up an average one.
> 
>    But do we believe OpenDNSSEC should be the solution for such
>    few-domain admins?  Or should they be redirected to a tool like
>    Holger's ZKT, which does well for smaller roll-out scenarios?
>    I think the dynamic-signer properties and use of PKCS #11 can
>    make OpenDNSSEC useful in places where ZKT is not active (yet).

OpenDNSSEC should be _the_ solution for such few-domain admins. The 
mandate that we have is that OpenDNSSEC should be the common tool for 
managing signed domains. If you have one domain, and want it signed, use 
OpenDNSSEC.

Fwiw I do not see a market for USB tokens as a keystore in this sense. USB 
tokens tend to get lost, stolen, or left connected to a device (or left in 
a bar or taxi, if you work for British Government). Note that data needs 
to be signed periodically and regularly. If you have a high value domain, 
use a proper fips-140-2 level 4 HSM. If you have huge number of highly 
volatile domains, use an HSM that is specifically build for acceleration. 
I think it is fine, in the general case, to have a softtoken.

> The next question then, is when key pairs could be shared?  Since a key
> coincides with responsibility to manage it, I suppose most deployments
> would stipulate that key pairs SHOULD at most be shared among zones
> administered by the same party.  As is the case with the example of the
> admin before.  As is the case with .co.uk and .org.uk.  But as is not 
the
> case when we are looking at nlnetlabs.nl, surfnet.nl and 
openfortress.nl.
> The latter three MUST NOT share a key pair.
> 
> > For a KSK rollover that is most tricky since you have 
> > to wait until all DS RRs at the parents are replaced, and then wait a 
> > little more, but I do not think that is not doable.
> 
> I also think it is doable.  It is very likely that there will be a sort
> of service level agreement about DS update times, because without that
> it is impossible to predict when to start rolling over.  (We could 
choose
> the times in RFC 4641, but it would be a matter of faith that the parent
> would adhere to it as well.)  Taking the worst-case DS update time 
should
> suffice to predict the key rollover preparation time.
> 
> > >>Not that one priv-key to many zones excludes many-to-many.
> 
> I do not think it is prudent to share keys among different parties, 
which
> would call for multiple keys on one OpenDNSSEC deployment.  However, 
I've
> been wondering when this would happen, and found only a somewhat 
contrived
> example.  A hoster (like SURFnet) could be willing to sign DNSSEC 
domains
> in an HSM for its constituents/customers.  There are probably legal
> considerations that make it necessary to have different keys for each
> customer/constituent, and enable local backup procedures by each of 
them.
> In such cases, it would be required to support different key pairs.
> 
> 
> In summary, I believe
> * that USB tokens make it necessary to share key pairs among zones
> * that provider-signing makes it necessary to support multiple key pairs

I see no issue with using a key for multiple domains. I see no issue with 
using a key per domain. Both policies can be implemented. 

Note though that I do not believe that USB tokens make it nec'cy to share 
key pairs among zones. See my earlier point.

Roy Arends
Sr. Researcher
Nominet UK