[Opendnssec-develop] Deactivating old KSK

[Stephen.Morris at nominet.org.uk]

Rickard Bellgrim <rickard.bellgrim at iis.se> wrote on 03/11/2009 10:33:52:

> > It does strike me that we need to get this sorted out fast though 
(i.e.
> > before 1.0).  In particular, the documentation should describe the
> > steps involved in doing a KSK rollover.
> 
> I was having a look on the documentation for the KSK rollover. You can 
issue 
> to command but there is more to it. We are lacking the possibility to 
notify 
> the system that it is safe to deactivate the old KSK.
> 
> So my statement is that there is no fully automatic solution for KSK 
rollover.
> Since we need interaction with our parent. Or in the case of the root, 
you 
> need to distribute the new trust anchor. Before we can deactivate the 
old KSK.
> 
> But OpenDNSSEC do act as if there KSK process is fully automatic...
> 
> I think that you never can solve this by using a timer. E.g. a 
configurable 
> time interval for the DS distribution.
> 
> We need a command for this.
> 
> // Rickard

The problem with a fully-automated system here is that although OpenDNSSEC 
can start publishing the new KSK in the zone, it has no way of knowing 
whether the DS record has been submitted to the parent (or even that the 
KSK rollover has been noticed by the operator).

I would suggest that the following requires a minimum amount of work to 
the enforcer:

a) New KSK is introduced into the zone automatically and messages appears 
in the logs. (This already happens.)
b) At some time, the new key moves into the "active" state and the old key 
into a "retire" state. In these states, both keys continue to be 
published. However, the enforcer is altered so as to set the amount of 
time the KSK stays in the "retire" state to some very large value.
c) The operator is required to acknowledge that the DS record has appeared 
in the parent.  This new command resets the retire time of the KSK to:

     max(TTL of record in parent zone + estimate of propagation delay 
through parent zone,
         TTL of record in this zone + estimate of propagation delay 
through this zone) +
         safety margin

d) The old KSK is not removed until the retire time has expired.  (In 
other words, we protect the user by keeping the old KSK in the zone for 
long enough to guarantee that the old DS and DNSKEY RRsets have expired 
from all validators.)

(Note that step (c) may occur before step (b), in which case step (b) 
should not reset the retire time.)

Stephen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20091103/18dfdb25/attachment.htm>