The problem with key tag collisions is that you turn verify operations from 1 per RRset to 1.5 per RRset for a two RRSIGS with the same tag and algorithm. You can figure out the average number of verify operations with 3, 4 etc. Those extra verify operations are completely avoidable by rejecting a new key which would cause a key tag collision. Generating a new key is not hard to do. Adding a check against the common key store is not hard to do in a multi-signer scenario. It can be completely automated. Request the set of in use tags. Generate a new key that doesn’t collide. Try to reserve the new key tag. Repeat if necessary.
We could even use the DNS and UPDATE to do that. Records with tuples of algorithm, tag and operator. Grab the current RRset. Add it as a prerequisite with a update for the new tag. -- Mark Andrews > On 17 Feb 2024, at 05:47, Paul Wouters <p...@nohats.ca> wrote: > > On Feb 16, 2024, at 12:17, Petr Špaček <pspa...@isc.org> wrote: >> >> >> It does not handle collisions in any special way. It simply does not >> validate and the resolver has no way to tell if the crypto thingy is wrong >> or if it just tried a wrong key. Any such failure is counted towards >> fail-budget (1 allowed). > > So a key tag collision with a sha1 to sha2 rollover with dual signing on a > rhel/centos box with sha1 disabled leads to servfail instead of insecure > answer ? Should I file a bug for that ? > > Paul > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
