(resent due to list hiccups - if anyone gets multiple messages, I apologize)
I would also mention in the text that this problem applies to a zone migrating from NSEC to NSEC3 (when using RSA/SHA-1) The algorithm code is used to signal it so it would appear to resolvers as two different algorithms. Scott On Sep 4, 2008, at 5:50 AM, Jelte Jansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi, > > during some work on DNSKEY maintenance, I think i found a potential > operational issue. If we are going to do new work on DNSSEC > Operational > Practices, I would like to suggest to add a text similar to that > attached to this message. > > The issue lies in the combination of algorithm downgrade protection > and > caching, and can result in a small window of time (depending on TTLs), > where all data in a zone could be considered bogus by validators. > > RFC4035 states the following (section 2.2): > > There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. > > While this poses no problem when an admistrator rolls a key with an > algorithm that is already present in the keyset, it can do so when > introducing new or removing old algorithms. > > Caches may have both the old keyset and the old rrsets with signatures > stored. When a new keyset is introduced, and the keyset happens to > expire in the cache before the signatures do, the cache will retrieve > the new keyset. Since it still has the rrsets with old signatures, it > will see > no reason to update those. > > Now the validator will encounter a key with an algorithm for which > there are no signatures. This is prohibited by the earlier statement > in RFC4035, resulting in rejection of the data. > > When removing an old algorithm, the same problem can occur when the > signatures expire in the cache before the keyset. > > This can be prevented by not adding or removing both the keys and the > signatures at the same time. > > Proposed addition to rfc4641diff attached in the hopes that the text > is > not mangled by my mail client. It might need a bit more of the problem > description though. > > Any thoughts? > > Jelte > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAki/r2YACgkQ4nZCKsdOncU9FACgoDkXP0PUjrdZTiJmiXNpxJ8X > oMEAoJBougDT51O6MacOpzoV8/5ZsUyg > =ab7S > -----END PGP SIGNATURE----- > > When rolling key algorithms (either adding a new algorithm, removing > an old algorithm, or both), additional steps are needed to retain > integrity during the rollover. > > Because of the algorithm downgrade protection in RFC4035 section 2.2, > you may not have a key of an algorithm for which you do not have > signatures. > > When adding a new algorithm, the signatures should be added > first. After the TTL has expired, and caches have dropped the old data > covered by those signatures, the DNSKEY with the new algorithm can be > added. When removing an old algorithm, the DNSKEY should be removed > first. > > To do both, the following steps can be used. For simplicity, we use a > zone that is only signed by one zone signing key. > > ---------------------------------------------------------------- > 1 Initial 2 New RRSIGS 3 New DNSKEY > ---------------------------------------------------------------- > SOA0 SOA1 SOA2 > RRSIG1(SOA0) RRSIG1(SOA1) RRSIG1(SOA2) > RRSIG2(SOA1) RRSIG2(SOA2) > > DNSKEY1 DNSKEY1 DNSKEY1 > RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2 > RRSIG2(DNSKEY) RRSIG1(DNSKEY) > RRSIG2(DNSKEY) > ---------------------------------------------------------------- > 4 Remove DNSKEY 5 Remove RRSIGS > ---------------------------------------------------------------- > SOA3 SOA4 > RRSIG1(SOA3) RRSIG2(SOA4) > RRSIG2(SOA3) > > DNSKEY2 DNSKEY2 > RRSIG1(DNSKEY) RRSIG2(DNSKEY) > RRSIG2(DNSKEY) > ---------------------------------------------------------------- > > In step 2, the signatures for the new key are added, but the key > itself > is not. While in theory, the signatures of the keyset should always be > synchronized with the keyset itself, it can be possible that RRSIGS > are > requested separately, so it might be prudent to also sign the DNSKEY > set with the new signature. > > After the cache data has expired, the new key can be added to the > zone, > as done in step 3. > > The next step is to remove the old algorithm. This time the key needs > to be removed first, before removing the signatures. The key is > removed > in step 4, and after the cache data has expired, the signatures can be > removed in step 5. > > The above steps ensure that during the rollover to a new algorithm, > the integrity of the zone is never broken. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop =================================== Scott Rose NIST [EMAIL PROTECTED] ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =================================== _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
