Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Andrews wrote: What I'm getting from this is that the keyset at the apex must (at least) be signed by each algorithm in the DS referral, and every rrset in the zone must be signed by each algorithm in the apex keyset. which is referred to by a DS / trust anchor. DNSKEY's are never referenced in isolation. There is always a DS / trust anchor which specifies which algorithms are in use. is that actually said anywhere in the DNSSEC RFCs? Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwliF4nZCKsdOncURAqMFAKDHV8eQ9E8zLnr5FsSvBL+wkWPgtQCgln2n xKvYKLTX8DkH9A5QMvoDgTE= =szS2 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
(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 SOA0SOA1 SOA2 RRSIG1(SOA0)RRSIG1(SOA1) RRSIG1(SOA2) RRSIG2(SOA1) RRSIG2(SOA2) DNSKEY1 DNSKEY1DNSKEY1 RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2 RRSIG2(DNSKEY) RRSIG1(DNSKEY) RRSIG2(DNSKEY) 4 Remove DNSKEY 5 Remove RRSIGS SOA3SOA4 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
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Resending my message because of the ietf mailing list problems - Original Message Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section Date: Fri, 05 Sep 2008 10:32:35 +0200 From: Jelte Jansen [EMAIL PROTECTED] To: Mark Andrews [EMAIL PROTECTED] CC: dnsop@ietf.org References: [EMAIL PROTECTED] Mark Andrews wrote: No. The DS / published trust anchor indicates support for the algorithm. Just having a DNSKEY at the apex does not indicate support for a algorithm. We must be reading this part differently... 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). What I'm getting from this is that the keyset at the apex must (at least) be signed by each algorithm in the DS referral, and every rrset in the zone must be signed by each algorithm in the apex keyset. Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwVz34nZCKsdOncURAskUAKCyD/4RFmp5urc2aJjP1sZfdxcSTQCfVcWj kN7cm1ZnZqOqi8HfB16ECeo= =Z2Mw -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
And Mark's reply to my previous message: Original Message Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section Date: Fri, 05 Sep 2008 18:39:49 +1000 From: Mark Andrews [EMAIL PROTECTED] To: Jelte Jansen [EMAIL PROTECTED] CC: dnsop@ietf.org Mark Andrews wrote: No. The DS / published trust anchor indicates support for the algorithm. Just having a DNSKEY at the apex does not indicate support for a algorithm. We must be reading this part differently... 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). What I'm getting from this is that the keyset at the apex must (at least) be signed by each algorithm in the DS referral, and every rrset in the zone must be signed by each algorithm in the apex keyset. which is referred to by a DS / trust anchor. DNSKEY's are never referenced in isolation. There is always a DS / trust anchor which specifies which algorithms are in use. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] suggestion for 4641bis: key algorithm rollover section
-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 SOA0SOA1 SOA2 RRSIG1(SOA0)RRSIG1(SOA1) RRSIG1(SOA2) RRSIG2(SOA1) RRSIG2(SOA2) DNSKEY1 DNSKEY1DNSKEY1 RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2 RRSIG2(DNSKEY) RRSIG1(DNSKEY) RRSIG2(DNSKEY) 4 Remove DNSKEY 5 Remove RRSIGS SOA3SOA4 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
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Andrews wrote: It's not a issue. You remove the DS's which have that algorithm then once they have expired from caches you can remove the DNSKEY. That could still leave the zone itself in an inconsistent state... I'm not talking about the DS-child apex case, but the apex-zone data case. If there is a DS with algorithm A then you have to have the entire zone signed with that algorithm. Once the DS has gone then that requirement no longer exists. The DNSKEY that is removed or added doesn't have to be one that is pointed to by a DS. Merely being present in the apex implies that there should be signatures of that algorithm in the zone. No. The DS / published trust anchor indicates support for the algorithm. Just having a DNSKEY at the apex does not indicate support for a algorithm. Mark If you don't add/remove all keys at the same time, the first or last DNSKEY couldn't even be a KSK; since those keys aren't used to sign the zone data, having a KSK as the only key of a certain algorithm number would always violate section 2.2. Unless of course I am misreading that MUST there :) Jelte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki/444ACgkQ4nZCKsdOncVoEACg2XThBDfSoUosRQBUTDcL2jYg bKkAoKNU4hLa/s5/xPlGVQp6XKXV7Uyv =TLej -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
On Thu, 4 Sep 2008, Mark Andrews wrote: It's not a issue. You remove the DS's which have that algorithm then once they have expired from caches you can remove the DNSKEY. Of course, you can replay them, resulting in a DOS. (I'll call this attack 6) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
