[Opendnssec-develop] KSK Rollovers

[Stephen.Morris at nominet.org.uk]

Following the last telephone meeting, I said that I would put something on 
the list about KSK rollover for people to check the logic.

The timing diagram for such a rollover is:

           |1|         |2|   |3|        |4|         |5|
            |           |     |          |           |
Key N     - - -------------------------->|<--------->|
            |           |    est      retired       dead
            |           |   retire       |           |
            |           |    time        |           |
            |           |     |          |           |
Key N+1     |<--------->|<-------------->|<--------- - - -
        published     ready   |        active        |
                              |          | 
                         "submit DS"  "DS seen"

                        ------- Time ----->

(This should be displayed correctly in a fixed-width font.)  The numbers 
above each line correspond to an event described below.


1) At least

   child propagation time + child zone TTL + safety margin

... 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.

("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.)

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.

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.

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.

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.) 

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.

The scheduled dead time for the old KSK is set to:

   active time + parent propagation time + parent zone TTL + safety margin

(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.)

5) At the first run of the signer after the old KSK reaches its scheduled 
dead time, the old KSK can be removed.


Caveats:
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.



Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20091119/ada8e5d9/attachment.htm>