This expectation setting. Adjusting key generation won’t happen unless there is a written requirement for it to happen. If we where to say duplicate keys tags are no longer supported as of date X there is no way the operators of all the existing signed zones with duplicate tags would know to perform key rolls. We have a chance that when new algorithms are added the key generation software will be updated to enforce uniqueness (for all algorithm). Operators of zones that generate duplicate tags and have the validation fail will not have a leg to stand on with their complaints. "Go tell your vendor to fix their software" will be the response.
Even if we where to go with one failure is allowed we still need to write down the new rules and there will be complaints that we are retrospectively changing the rules. This is grand fathering in the old rules for the old algorithms. Mark > On 26 Jul 2024, at 14:55, John Levine <jo...@taugh.com> wrote: > > It appears that Paul Hoffman <paul.hoff...@icann.org> said: >> The problems are listed as: >> >> Colliding key tags impose additional work on a validating resolver, which >> then has to check >> signatures for each of the candidate set of keys identified by the Key Tag. >> Furthermore, they >> open up resolvers to computational denial of service attacks by adversaries >> deploying specially >> crafted zones with many intentionally colliding key tags [KEYTRAP]. > > I don't see why this is a problem that needs to be solved. I did a > survey of the names in all the large gTLD zones and I never found more > than a single collision per delegated zone. Resolvers can stop after, > say, three collisions with a negligible chance of losing real DNS > data. (Zones built with deliberate collisions don't count.) This is > just one more implementation limit that started with the CNAME limit > suggested in 1035. > > I suppose we can suggest that people adjust their key generation > systems to check the old and new keys, and regnerate the new key if > there's a collision, but that is a minor and not very important tweak. > > R's, > John > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
