[Opendnssec-develop] v1.1 RC1

[Stephen.Morris at nominet.org.uk]

Matthijs Mekking <matthijs at NLnetLabs.nl> wrote on 31/03/2010 11:07:40:

> Rickard Bellgrim wrote:
> > * We are still struggling with dropped signatures during key rollover.
> 
> Currently a key rollover is done this way:
> 
> 1. K1[a]   ->   K1[ac], K2[p]   ->   K1[p], K2[a]   ->   K2[a]
> 
>    Where a is active and p is publish.

To avoid confusion, can I suggest that we use the term "retired" when a 
key is replaced.  The sequence then becomes:

1. K1[a]   ->   K1[a], K2[p]   ->   K1[r], K2[a]   ->   K2[a]

Where a is active, p is publish and r is retired.

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.

> 
> 2. If such a change happens in the enforcer, the signer will be
>    notified: ods-signer update <zone>
> 
> 3. The signer will resign when there is a change in the key set.
> 
> 4. Because the signer has no knowledge of key rollovers, it just follows
>    orders that are given in the signconf file, it will drop all
>    signatures when K1 transitions to published state. It will create all
>    new signatures with K2, because it just became active.

The key timing draft (
http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02) take 
this into account by stating that the old key needs to be retained in the 
zone for a period of time equal to:

   Dsgn + Dprp + TTLsig

... where

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.

Dprp is the propagation delay, the time taken for any change to the zone 
to reach all slave servers.

TTLsig is the TTL of the RRSIG record, the time taken for an RRSIG to 
expire from a resolver cache.

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.

> I hear that there is a need between a smooth transition between step 2
> and 3 of the key rollover process. However, this requires a new state:
> 'publish, but pre-generate signatures with this key if there are no
> fresh signatures for current active keys, but don't publish those
> signatures yet'. This will replace the publish state in the above 
situation.

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

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.


> When the old key becomes inactive (but still is post-published), I think
> we should drop all old signatures, regardless of the freshness of these
> signatures, as they should not be propagated anymore towards the caches.

If we can do this within time constraints, this is simpler still.

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