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
