[Opendnssec-develop] v1.1 RC1

[Matthijs Mekking]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen.Morris at nominet.org.uk wrote:
> 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.

Yes. and this is what we currently do within OpenDNSSEC, I believe.

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

However, the signer cannot distinguish between a published or a retired
key. What I get from this is that you propose to change the meaning of
published with respect to the signer, that is: this key is published and
should also replace signatures of other keys that are about to expire
(should the current active key also create a signature over the same
RRset). We need a new state, retired, that means: just publish this key,
don't use it for signing (the current definition of publish).

We really should think over what the signer should do in different use
cases. As we will introduce algorithm rollover, I foresee new states in
which the signer should not be published, but does need to publish
signatures.

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

This is not an alternative, I think it is a requirement. Although if we
have a state were the new key will pre-generate signatures, this switch
is not that hard (computationally).


Matthijs



> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJLs0t1AAoJEA8yVCPsQCW5v/QIAKySTazITO45UuB1RMU6F24O
7o51LGVdzVsrnbXW1e4ZlRZJHHFNnOLFmoa0qZVU5t33fScOX9eZtM0IHG5sywQq
5ZAWmkTL5PH2cUistucMZ+Trz/pm4umOxBrtL/T1LKw69myGP9TRLxe+v8BDFwvb
SVsfnwWiccyBw1mZszQq+qpa0yvFPgveWCl/Dyc1eNWwnb5cbbxWJe7b2v5Iwnmh
r9lFLpCMO6XONQytGBB77yhvma/6qssRwg/25t8jkPfHJEaokCP7s3K/LoOgqZ45
rgc5z5CHCSaAyxCLPN/5rxvgGfrj+rz9KW9QS2Ofq2ych4t0AVRyKmCqY5G5X94=
=p18e
-----END PGP SIGNATURE-----