To:
Edward Lewis <lewis@tislabs.com>
Cc:
Olaf Kolkman <OKolkman@ripe.net>, dnssec@cafax.se
From:
Simon Josefsson <simon+dnssec@josefsson.org>
Date:
Wed, 04 Jul 2001 20:00:57 +0200
Delivery-Date:
Thu Jul 5 12:17:15 2001
In-Reply-To:
<v03130300b768bafcba9d@[192.94.214.137]> (Edward Lewis'smessage of "Wed, 4 Jul 2001 08:27:48 -0400")
Sender:
owner-dnssec@cafax.se
User-Agent:
Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103
Subject:
Re: ttl problems in DNSSEC
Edward Lewis <lewis@tislabs.com> writes: > At 4:18 AM -0400 7/4/01, Olaf Kolkman wrote: >> >>I think that the problem is not that K++1 is removed but that the data >>is not signed with S++1. >> >>IMO this is the solution: After the rollover NS MUST sigh the data in >>it's zone with both keys for a period that is at least the TTL of the >>old key (K++1) > > I think this would be heading in the wrong direction. When retiring a key > you want to remove the signatures, not perpetuate them. Depends on the reason: Key compromise: Right. The compromised key should not be used to sign things nor advertised [by the real owner]. Key rollover: This is different, and there's no reason (besides having yet another extra things to keep in mind when using DNSSEC) why two keys can't sign the sone during a transition period. Especially if this reduces complexity in resolvers, like in the case in this thread. One conclusion is that key compromises cannot in general be detected until TTLs have expired, but this is hardly a surprise I think. This may be one reason to use a low TTL on KEY records. Another conclusion is that we should decide if key-rollover using two keys is worth the extra administrative burden (i.e. if it should be recommended practice). It might be possible to design resolvers etc to handle this situation correctly instead, but this require more complexity in software and slightly more trafic when keys are changed. I dunno which is worse.