> On 28 Feb 2024, at 05:52, Peter Thomassen <pe...@desec.io> wrote: > > > > On 2/16/24 17:19, Jim Reid wrote: >>> If a zone's signatures and keys are constructed and published in such a way >>> that it causes indigestion in validators, and as a consequence validators >>> fail to return responses for data in that zone, that's a self-inflicted >>> problem and the zone administrator surely has every incentive to fix the >>> problem. If the tools the zone administrator is using make the problem hard >>> to make, then so much the better. >> If validators can also make this problem hard to make, that’s so much the >> better too. That should give signers a strong incentive to fix their >> self-inflicted problem and stop hurting validating resolvers. > With (some) validators returning SERVFAIL when encountering a keytag > collision, any operator adding a DNSKEY (e.g., for rollover) will, in roughly > 2^-16 of cases, break their zone without notice. > > It's not clear to me how one would characterize such validator policy as > "mak[ing] this problem hard to make". > > It rather seems like inviting instability, then telling the signer "well, you > knew...! Or should have, at least." > > I don't see in what way that's better than what we have with the current > fixes, which successfully address the problem and (AFAICS) don't need to be > touched again.
The current “fixes” still leave validators more vulnerable to cpu exhaustion attacks than eliminating colliding key tags in the signer does. This is a protocol bug that leads to cpu exhaustion. We, the IETF, have a duty to fix this at the protocol level. Vendors of signers then have a duty to fix this in their products. It that requires writing new tools to co-ordinate in the multi-signer scenario then so be it. I write the last as a vendor that would need to write such a tool. We have spent time bringing down the number of iterations in NSEC3 records due to CPU exhaustion. What is the difference with fixing this with DNSKEYs? Is it "I don’t want to touch my code”? > Best, > Peter > > _______________________________________________ > 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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
