[Dnssec-deployment] Barbie sez: "Algorithm rollovers are HARD!"
michael at rancid.berkeley.edu
Mon Aug 16 10:22:06 EDT 2010
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:
>> 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
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.
More information about the Dnssec-deployment