<tt><font size=2>Following the last telephone meeting, I said that I would
put something on the list about KSK rollover for people to check the logic.</font></tt>
<br>
<br><tt><font size=2>The timing diagram for such a rollover is:</font></tt>
<br>
<br><tt><font size=2> |1|
|2| |3| |4|
|5|</font></tt>
<br><tt><font size=2> |
| |
| |</font></tt>
<br><tt><font size=2>Key N - - -------------------------->|<--------->|</font></tt>
<br><tt><font size=2> |
| est retired
dead</font></tt>
<br><tt><font size=2> |
| retire |
|</font></tt>
<br><tt><font size=2> |
| time |
|</font></tt>
<br><tt><font size=2> |
| |
| |</font></tt>
<br><tt><font size=2>Key N+1 |<--------->|<-------------->|<---------
- - -</font></tt>
<br><tt><font size=2> published
ready | active |</font></tt>
<br><tt><font size=2>
|
| </font></tt>
<br><tt><font size=2>
"submit DS" "DS
seen"</font></tt>
<br>
<br><tt><font size=2>
------- Time -----></font></tt>
<br>
<br><tt><font size=2>(This should be displayed correctly in a fixed-width
font.) The numbers above each line correspond to an event described
below.</font></tt>
<br>
<br>
<br><tt><font size=2>1) At least</font></tt>
<br>
<br><tt><font size=2> child propagation time + child zone TTL
+ safety margin</font></tt>
<br>
<br><tt><font size=2>... before the current KSK reaches the end of its
scheduled lifetime, we introduce the new KSK into the zone. The DNSKEY
RRset is signed with both KSKs, and the new KSK is placed in the "published"
state.</font></tt>
<br>
<br><tt><font size=2>("child propagation time" is the time taken
for an RR introduced at the child's master nameserver to have reached all
nameservers serving the child zone. "child zone TTL" is
the TTL of RRs in the child zone, in particular the TTL of the DNSKEY RRs.
"safety margin" is as its name suggests, an additional
time period added so that we are _completely_ sure that the record has
propagated.)</font></tt>
<br>
<br><tt><font size=2>The interval is such that at the point that the current
KSK reaches the end of its scheduled lifetime, any validator that has cached
the DNSKEY RRset will have a copy that contains [and is signed by] both
the old and new KSKs.</font></tt>
<br>
<br><tt><font size=2>2) At some later time, the new KSK is "ready".
That is, all validators that have the DNSKEY RRset in their cache
have a copy of both keys. This will be at or before the current KSK
reaches its estimated retire time, depending on exactly when the new KSK
was introduced.</font></tt>
<br>
<br><tt><font size=2>3) When the current KSK reaches its estimated retire
time, the KASP enforcer starts outputting messages that the DS record in
the parent must be changed. The messages should indicate what the
new key is, and there has to be some way to extract the DS record for transmission
to the parent.</font></tt>
<br>
<br><tt><font size=2>4) At some later time, the new DS record is seen in
the parent zone and the old one removed. (At this point, as all validators
that have cached the DNSKEY RRset have both KSKs in their cache, it doesn't
matter whether a validator checks against the new DS record or the old
one (having retrieved the old one just before it was removed from the parent);
at least one of the KSKs will match.) </font></tt>
<br>
<br><tt><font size=2>The operator issues the "ds-seen" command
to tell KASP about this. This command moves the old KSK into the
"retired" state and the new KSK into the "active" state.</font></tt>
<br>
<br><tt><font size=2>The scheduled dead time for the old KSK is set to:</font></tt>
<br>
<br><tt><font size=2> active time + parent propagation time
+ parent zone TTL + safety margin</font></tt>
<br>
<br><tt><font size=2>(As we have no way of knowing when the DS record actually
appeared in the parent, we assume the worst. The interval allows
for the ds-seen command being issued the moment the DS record appears at
the primary server of the parent zone: after (parent propagation time +
parent zone TTL + safety margin), any validator that contains the DS RRset
will have a copy of the RRset containing the new DS record. As, at
this point, the validator will also have the DNSKEY RRset containing the
new KSK, it will able to validate the zone with the new KSK and DS records.
The old KSK is now redundant.)</font></tt>
<br>
<br><tt><font size=2>5) At the first run of the signer after the old KSK
reaches its scheduled dead time, the old KSK can be removed.</font></tt>
<br>
<br>
<br><tt><font size=2>Caveats:</font></tt>
<br><tt><font size=2>If the operator issues the ds-seen command, the command
MUST be ignored unless the DS record corresponds to that of a key in the
ready state. Otherwise we run the risk that the old KSK is removed
before all validators have received a copy of the new DS record, leading
to a KSK-DS mismatch and the zone being declared bogus.</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>Stephen</font></tt>