<tt><font size=2>Matthijs Mekking <matthijs@NLnetLabs.nl> wrote
on 31/03/2010 11:07:40:</font></tt>
<br><tt><font size=2><br>
> Rickard Bellgrim wrote:<br>
> > * We are still struggling with dropped signatures during key
rollover.<br>
> <br>
> Currently a key rollover is done this way:<br>
> <br>
> 1. K1[a]   ->   K1[ac], K2[p]   ->   K1[p],
K2[a]   ->   K2[a]<br>
> <br>
>    Where a is active and p is publish.</font></tt>
<br>
<br><tt><font size=2>To avoid confusion, can I suggest that we use the
term "retired" when a key is replaced.  The sequence then
becomes:</font></tt>
<br>
<br><tt><font size=2>1. K1[a]   ->   K1[a], K2[p]   ->
  K1[r], K2[a]   ->   K2[a]<br>
</font></tt>
<br><tt><font size=2>Where a is active, p is publish and r is retired.</font></tt>
<br>
<br><tt><font size=2>When a key moves to the retired state, no new signatures
are created with it; it is only published in the zone to cope with RRSIGs
created by it that may still be in the zone file or in caches.</font></tt>
<br><tt><font size=2><br>
> <br>
> 2. If such a change happens in the enforcer, the signer will be<br>
>    notified: ods-signer update <zone><br>
> <br>
> 3. The signer will resign when there is a change in the key set.<br>
> <br>
> 4. Because the signer has no knowledge of key rollovers, it just follows<br>
>    orders that are given in the signconf file, it will drop
all<br>
>    signatures when K1 transitions to published state. It
will create all<br>
>    new signatures with K2, because it just became active.</font></tt>
<br>
<br><tt><font size=2>The key timing draft (</font></tt><a href="http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02"><tt><font size=2>http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02</font></tt></a><tt><font size=2>)
take this into account by stating that the old key needs to be retained
in the zone for a period of time equal to:</font></tt>
<br>
<br><tt><font size=2>   Dsgn + Dprp + TTLsig</font></tt>
<br>
<br><tt><font size=2>... where</font></tt>
<br>
<br><tt><font size=2>Dsgn is the time taken to re-sign the zone, i.e. the
interval between the time the new key becomes active and the time that
the last signature created with the old key is replaced.</font></tt>
<br>
<br><tt><font size=2>Dprp is the propagation delay, the time taken for
any change to the zone to reach all slave servers.</font></tt>
<br>
<br><tt><font size=2>TTLsig is the TTL of the RRSIG record, the time taken
for an RRSIG to expire from a resolver cache.</font></tt>
<br>
<br><tt><font size=2>In step 4 above, when a new key becomes active, the
next run of the signer drops all RRSIGs created by the old key and replaces
them with RRSIGs created with the new key.  This is effectively setting
Dsgn to 0; the old key needs to be retained for as long as it takes for
the new signatures to reach all slave servers and then replace any cached
signatures.</font></tt>
<br>
<br><tt><font size=2>> I hear that there is a need between a smooth
transition between step 2<br>
> and 3 of the key rollover process. However, this requires a new state:<br>
> 'publish, but pre-generate signatures with this key if there are no<br>
> fresh signatures for current active keys, but don't publish those<br>
> signatures yet'. This will replace the publish state in the above
situation.</font></tt>
<br>
<br><tt><font size=2>The drawback of replacing signatures all at once is
that if it is a large zone with a lot of signatures, the time taken to
re-sign the zone may become significant.  This can be overcome by
creating the signatures over a period of time.  The obvious approach
being to replace the signatures only as they approach their expiry time.
 This fits in with the existing algorithm: in this case, Dsgn (the
time taken to re-sign the zone) is non-zero, being equal to (signature
validity period - refresh interval).</font></tt>
<br>
<br><tt><font size=2>The penalty is that the second key, K2, is in the
zone for longer than it would otherwise be.  However, implementation
of this option may be simpler than the option suggested above, i.e. generating
(but not publishing) signatures when the new key appears.</font></tt>
<br>
<br><tt><font size=2><br>
> When the old key becomes inactive (but still is post-published), I
think<br>
> we should drop all old signatures, regardless of the freshness of
these<br>
> signatures, as they should not be propagated anymore towards the caches.</font></tt>
<br>
<br><tt><font size=2>If we can do this within time constraints, this is
simpler still.</font></tt>
<br>
<br><tt><font size=2>Stephen</font></tt>