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

W.C.A. Wijngaards wouter at NLnetLabs.nl
Mon Aug 16 03:03:54 EDT 2010


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

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

Best regards,
   Wouter

> 
> 5. AFTER waiting TTL+propagation delay of the DSSet, DNSKEYs with old
> algorithm can be "safely" removed.
> 
> The problem is that this method can lead to validation failures and zone
> bogusity if not done exactly right.  The reason is to accommodate those
> implementations that enforce (probably correctly) a strict
> interpretation of the last paragraph of section 2.2 of RFC 4035:
> 
>    "There MUST be an RRSIG for each RRset using at least one DNSKEY of
>    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>    itself MUST be signed by each algorithm appearing in the DS RRset
>    located at the delegating parent (if any)."
> 
> Here's the wrinkle: Although I can remove all algo 5 DS records in the
> parent, as long as I have an algo 5 DNSKEY in the DNSKEY RRSet, I MUST
> continue to sign with algo 5 (using, of course, one of the algo 5 keys
> in that DNSKEY RRSet).  Moreover, clients who have cached the DNSKEY
> records WILL experience validation failures until TTL+propagation delay
> after you remove the algo 5 DNSKEYs, *if* you stop signing with those
> keys when you remove them.  I have verified this with such an
> implementation (unbound 1.4.6, which strictly enforces RFC 4035 section
> 2.2).
> 
> The irony is that RFC 4035 section 2.2 is designed to prevent algorithm
> downgrade attacks, but it also makes *upgrading* algorithms more difficult.
> 
> The answer is to continue signing with the algo 5 keys but not include
> them in the DNSKEY RRSet.  This shouldn't cause problems, since new
> clients will only see the algo 10 DS records and associated DNSKEYs, and
> the multiple RRSIGs don't violate the other parts of section 2.2 AS LONG
> AS there is at least one RRSIG whose signing key's public counterpart
> exists in the zone apex DNSKEY RRSet (which it does in this example).
> Having additional RRSIGs shouldn't be a problem as long as one matches
> one of the DNSKEYs and there are only algo 10 DNSKEYs in the DNSKEY RRSet.
> 
> Whew!  So what this means is that my #5 should be rewritten as:
> 
> 5. AFTER waiting TTL+propagation delay of the DSSet, DNSKEYs with old
> algorithm can be "safely" removed from zone DNSKEY RRSet, but zone will
> still need to be signed with recently-removed keys.
> 
> 6. AFTER waiting TTL+propagation delay of the DNSKEY RRSet, zone can
> then be signed only with the new algorithm.  The old private keys can be
> discarded.  Administrators may want to lower the TTLs of the DNSKEY
> RRSet in order to minimize the time between steps 5 and 6.
> 
> I wonder if folks have thoughts on this, and if anyone knows of a howto
> that has clarified these issues.  The logic here is exactly the opposite
> of a ZSK rollover, where keys are present but aren't signing anything,
> and it requires a bit more coordination than a typical KSK rollover
> because you have to keep signing with the old algorithm to deal with
> cached DNSKEY RRSets.  Do any of the automated management tools support
> this type of rollover?  (I use zkt and it does not--you have to do a lot
> of manual work and shim scripting to make this happen gracefully.)
> 
> I think the moral of the story is "the more algorithm rollovers you can
> avoid, the better."
> 
> michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxo4toACgkQkDLqNwOhpPirGgCgs31tp9lQYgNID4sNkZPiKdsU
uHQAn0XTXsb4NkKBoMarsAKWc2gSqtlL
=xP47
-----END PGP SIGNATURE-----


More information about the Dnssec-deployment mailing list