I think it might be worth distinguishing between caching validators and end validators. For an end validator, doing a second validation is not going to be a serious issue. The Apple DNSSEC validator currently does not allow key tag collisions at all, but it's not yet in heavy use so I wouldn't want to suggest that this is the correct behavior. In our internal discussions we've concluded that allowing a single collision is okay; more than that is not okay. But our validator isn't going to be easily subject to the kinds of attacks we're talking about, because it's on an end device.
The case Ralf is talking about is probably the more important case to consider. In Akamai's case, this attack is much more likely to actually cause a serious problem. So allowing a multiplier of 10 seems bad. Allowing a multiplier of 2 (allowing one collision) is also fairly bad. It really doesn't seem that hard to me to completely forbid key tag collisions. I'd like to hear a clear argument for why that's not doable, and not just some hand-waving about how it's complicated and someone might get it wrong. Zones with multiple offline signers are as far as I know the exception, not the rule. I think we can come up with some straightforward heuristics for ensuring that we get it right in those cases. It really should not be on the caching resolver providers to pay the cost of poor authoritative server operational practices. On Thu, Feb 29, 2024 at 7:52 AM Edward Lewis <edward.le...@icann.org> wrote: > *From: *DNSOP <dnsop-boun...@ietf.org> on behalf of Shumon Huque < > shu...@gmail.com> > *Date: *Wednesday, February 28, 2024 at 16:22 > *To: *Edward Lewis <edward.le...@icann.org> > *Cc: *John Levine <jo...@taugh.com>, "dnsop@ietf.org" <dnsop@ietf.org> > *Subject: *Re: [DNSOP] [Ext] About key tags > > > > >… I think writing a BCP telling folks how to avoid collisions would make > sense though (and yes, it needs to cover the multi-signer case too). > > > > I support that. Key tag collisions make one of my pet projects > (visualizing key management over time) cry. And collisions are a > multiplier in a malicious use case. Discouraging them is a good thing. > > > > The point I’m belaboring is how the issue of resource over consumption is > addressed matters. We can’t ban the problem out of existence, even if it > were simple to restrict it from ever happening, we need to enforce this > where the resources at risk are managed. > > > > If this means a validator experiences some false positives, I could live > with that. There are very few good reasons to have a complex DNS set up > and such situations are supported and tolerated in the protocol that > doesn’t mean they are good ideas or have simpler alternatives. > Discouraging wacky configurations isn’t a terrible thing to do, especially > since we can have (or imagine) highly complex signing scenarios which > could, if the planets align correctly, permit a key tag collision no matter > to what length we go to prevent a collision from seeing the light of day. > > > > Keeping in mind - this entire topic is covering the non-usual state of the > protocol, one that fears a malicious activity I believe has not been > encountered in the wild. (If no action is taken, malicious activity might > follow now that it is described, but I have not heard of a historical case > of it.) We are dealing with the odd, we need to mitigate its impact, > eliminating it might just be -relatively speaking - too much work. > _______________________________________________ > 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
