[Dnssec-deployment] Barbie sez: "Algorithm rollovers are HARD!"

[Michael Sinatra]

On 08/16/10 00:03, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Michael,
>
> Quick mistakes, see below.
>
> On 08/16/2010 08:07 AM, Michael Sinatra wrote:
>> Part of the issue that comes up when deciding with which algorithm to
>> initially sign your zone is the difficulty of algorithm rollovers.  I
>> have pointed this out elsewhere, but I am seeing it again as I undertake
>> an exercise to try think about how I would roll the algorithm for
>> berkeley.edu and all of its subzones from RSASHA1 to RSASHA512.
>>
>> The steps that I would take in doing this (I came up with these on my
>> own, but also validated them against Scott Rose's paper:
>> http://www-x.antd.nist.gov/dnssec/download/DNSSEC_Algorithm_rollover.pdf)
>>
>> 1. Generate KSK and ZSK with new algorithm.
>>
>> 2. Sign zone with existing KSK/ZSK algorithm and new KSK/ZSK algorithm
>> (accordingly, there will be four RRSIGs for the DNSKEY RRSet and two
>> RSSIGs for all other RRSets, which are signed by the respective ZSKs only).
>
> Same as Ondrej says, if someone is caching an old RRset+signature and
> fetches a new DNSKEY with the new algorithms that would be bogus.
> (validators may retry and thus fix this trouble for you, invisibly).
> Officially, first introduce signatures and after TTL, the DNSKEYs.

You and Ondrej are correct, and I was able to generate validation 
failures this way; I just forgot to document it.  This is the first 
point in the process where you have to be extra careful due to the "sign 
with all algorithms" requirement.

>> 3. Install new DS records in parent.
>>
>> 4. Remove old DS records from parent (I think Scott may have forgotten
>> this step in his paper).  I don't think you have to wait a for the usual
>> TTL+propagation delay (for the DSSet) for this because any new client
>> that grabs the DSSet from the parent will validate with the new algo and
>> any one that has the old DSSet cached will still be able to validate.
>> You will, however, have to wait for the TTL+propagation delay of the
>> DNSKEY RRSet, so that clients will have removed the old DNSKEY RRSet
>> from their caches.
>
> No, you must wait TTL here.  Because otherwise, someone may fetch the
> new DS set and get an OLD DNSKEY set, and that would not work, since the
> old DNSKEY set does not have that algorithm inside it.  (Again, if this
> does not show up in test, it could be due to validator retries.)

Yes, I actually did try to say that in #4, but it wasn't clear. 
Basically, what I was saying is that you had to wait for the DNSKEY 
TTL+propagation delay to expire, but you can simply replace the old DS 
record with the new one, *after* the DNSKEY TTL+propagation delay has 
passed.

In other words, there shouldn't be a time period when you MUST have both 
DS records present for both algorithms, unless you want to continue to 
support old clients that can only support the old algorithm (in which 
case you will need to have both DNSKEYs present and double-sign 
indefinitely).  Aside from that, this is the one step that is pretty 
much the same as the double-signature KSK rollover that Olaf documents 
in the draft.

Thank you both for the pointer to Olaf's draft; I am glad that this is 
being included in the update to 4641.  It's much clearer that what I 
said in my email.

michael