<tt><font size=2>Rickard Bellgrim <rickard.bellgrim@iis.se> wrote
on 03/11/2009 10:33:52:<br>
<br>
> > It does strike me that we need to get this sorted out fast though
(i.e.</font></tt>
<br><tt><font size=2>> > before 1.0).  In particular, the documentation
should describe the</font></tt>
<br><tt><font size=2>> > steps involved in doing a KSK rollover.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> I was having a look on the documentation for
the KSK rollover. You can issue <br>
> to command but there is more to it. We are lacking the possibility
to notify <br>
> the system that it is safe to deactivate the old KSK.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> So my statement is that there is no fully automatic
solution for KSK rollover.<br>
> Since we need interaction with our parent. Or in the case of the root,
you <br>
> need to distribute the new trust anchor. Before we can deactivate
the old KSK.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> But OpenDNSSEC do act as if there KSK process
is fully automatic...</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> I think that you never can solve this by using
a timer. E.g. a configurable <br>
> time interval for the DS distribution.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> We need a command for this.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> // Rickard</font></tt>
<br>
<br><tt><font size=2>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).</font></tt>
<br>
<br><tt><font size=2>I would suggest that the following requires a minimum
amount of work to the enforcer:</font></tt>
<br>
<br><tt><font size=2>a) New KSK is introduced into the zone automatically
and messages appears in the logs. (This already happens.)</font></tt>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2>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:</font></tt>
<br>
<br><tt><font size=2>     max(TTL of record in parent zone
+ estimate of propagation delay through parent zone,</font></tt>
<br><tt><font size=2>         TTL of record in
this zone + estimate of propagation delay through this zone) +</font></tt>
<br><tt><font size=2>         safety margin</font></tt>
<br>
<br><tt><font size=2>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.)</font></tt>
<br>
<br><tt><font size=2>(Note that step (c) may occur before step (b), in
which case step (b) should not reset the retire time.)</font></tt>
<br>
<br><tt><font size=2>Stephen</font></tt>
<br>
<br>
<br>
<br>