[Opendnssec-develop] Creating keys

[Roy Arends]

John Dickinson wrote on 11/27/2008 11:25:24 AM:

> Lacking anyone physically present who cares about DNS, DNSSEC or keys 
> to bounce thoughts off I am going to use this mailing list :)
> 
> I am working on the key creation logic of the enforcer.
> 
> A policy is used to specify key and signing parameters for a zone or 
> set of zones.
> 
> Lets look at an example, say the policy specifies that the algorithm 
> to be used for new KSKs is 5 and that the algorithm to be used for 
> ZSKs is 11. (ignore for now any technicalities of exactly how you 
> switch to a new algorithm.). Keys for both KSKs and ZSKs are to be 
> stored in security module 1.
> 
> The enforcer will start for the FIRST TIME and examine the policy - it 
> will see that it needs keys of types 5 and 11. It knows (because we 
> told it) that the capacity of security module 1 is 1000 keys.
> 
> Key generation is expensive so I was planning to pre-create as many 
> keys as possible.

Though I understand that key generation is expensive, in practice there is 
really no need to switch keys every minute. So, why not pre-create as many 
keys as needed, instead of as much as possible? I don't think there is a 
requirement that zones are dumped en-masse in the opendnssec daemon, and 
expected to work _on the spot_. I have no problem with a little initiation 
time. Keep in mind that when these zones are dumped en-mass, the 
key-generation time is not the bottleneck. Getting every zone completely 
signed asap is the bottleneck imho.

Hope this helps.

> So first of all I thought the Enforcer could create 
> 500 keys of each algorithm. Great - that is easy. But consider the 
> following events in the future...
> 
> 1. Additional policy using same key algorithms
> at some time later we create a second policy which specifies that it 
> needs KSKs with alg 5 and ZSKs with alg 5. Fine there are 500 (minus 
> any we have used) of alg 5 keys we just start using them for policy 2.
> 
> 2. Additional policy using new key algorithms
> at some time later we create a third policy which specifies that it 
> needs KSKs with alg 6 and ZSKs with alg 12. Oh no! the security module 
> is full. What do we do?
> 
> 3. Change an existing policy to use new algorithm.
> at some time later we modify the first policy to say that new keys 
> must use alg 94. Oh no! the security module is full. What do we do?
> 
> 
> Solution:
> This is the logic I intend use to get round this.
> Policy will also specify a minimum number of unused keys that must 
> exist.
> policy->zsk->alg = 5
> policy->zsk->keymincount = 100
> policy->ksk->alg = 11
> policy->ksk->keymincount = 20
> 
> as before there will be a known capacity of the security module. Lets 
> say 300.
> 
> The enforcer will start for the FIRST TIME and examine the policy - it 
> will see that it needs keys of types 5 and 11. It will create 100 alg 
> 5 and 20 alg 11 keys
> 
> 1. Additional policy using same key algorithms
> at some time later we create a second policy which specifies that it 
> needs 100 ZSKs with alg 5 and 20 KSKs with alg 11. Fine there is still 
> 180 spaces for keys in the security module - create another 100 alg 5 
> and 20 alg 11 keys
> 
> 2. Additional policy using new key algorithms
> at some time later we create a third policy which specifies that it 
> needs 200 ZSKs with alg 6 and 50 KSKs with alg 12. OK there is room 
> for the 50 alg 12 keys but not for 200 alg 6. So the Enforcer will 
> scan for dead keys and delete them. If there is now room for 200 more 
> keys then great - if not then WARN.
> 
> 3. Change an existing policy to use new algorithm.
> There was room... at some time later we modify the first policy to say 
> that new keys ksk and zsk must use alg 94 min still 100 and 20. the 
> Enforcer will scan for dead keys and delete them. If there is now room 
> for 120 more keys then great - if not then WARN.
> 
> Each time the policy is read a check will be made of the number of un- 
> used keys available. If for a particular algorithm there is less than 
> the sum over all policies of keymincount then new keys will be created.
> 
> Assuming keys are being used regularly this will cause new keys to be 
> created regularly. We might want a threshold saying don?t create new 
> keys unless we are x many below the minimum.
> 
> BTW if you set keymincount = a small number <= no of keys in use then 
> you are effectively saying don't pre-create keys.
> 
> Note: the above says nothing about keys getting used. Even if new keys 
> can not be created - If there are un-used keys available then 
> scheduled key rollovers will continue. If at any time there are no new 
> keys available then the Enforcer will scan for dead keys and delete 
> them. If there is now room for more keys then great - if not then key 
> rollover will stop - (re-)signing will always continue...
> 
> I am not really asking any questions but if what I wrote seems stupid 
> then please shout.


Roy