> On Feb 15, 2024, at 9:53 AM, Paul Hoffman <paul.hoff...@icann.org> wrote: > > On Feb 15, 2024, at 09:48, Wellington, Brian > <bwelling=40akamai....@dmarc.ietf.org > <mailto:bwelling=40akamai....@dmarc.ietf.org>> wrote: >> >> >> >>> On Feb 15, 2024, at 6:02 AM, Paul Wouters <p...@nohats.ca> wrote: >>> >>> On Feb 15, 2024, at 04:37, Petr Špaček <pspa...@isc.org> wrote: >>>> >>>> If you think colliding keys should be allowed, please propose your own >>>> limits for sensible behavior. >>> >>> I do think they need to be allowed because they have always been allowed so >>> far. Reasons for not allowing them seems to be implementation details. >>> Sure, if the RFCs had warned implementers this wouldn’t have happened, and >>> we can learn from that (and I gained appreciation and validation for >>> whining about security and operational consideration sections) >>> >>> You seem willing to (statistically) throw 1/65536 zones under the bus. That >>> would roughly be 2500 .com domains if all of .com was signed (without key >>> sharing) >>> >>> I don’t see why we should do this. >> >> A fairly simple way to deal with this issue is a Flag Day. As Ralf said in a >> later post, the number of zones with colliding key tags is relatively small. > > Anything above zero is significant.
Obviously. That’s why I suggested a Flag Day in the future, not an immediate change. That would give operators and implementors enough time to update existing zones and software. > >> It would certainly be reasonable to declare that at some time in the future, >> colliding keys will not be handled by validators. > > Why? Many people on this thread have said they have or will implement caps on > how many collisions for a key set they will allow. An operational change such > as that is vastly easier to implement than a flag day, and gets better > results. One reason is to avoid having another discussion like this after the next issue related to key tag collisions. Another is to simplify validator implementations, which reduces the risk of bugs. Another is to simplify operational debugging; it’s a lot easier to figure out why something’s failing if keys are uniquely identified within the protocol. Brian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
