On 2/14/24, 08:38, "DNSOP on behalf of Joe Abley" <dnsop-boun...@ietf.org on behalf of jab...@strandkip.nl> wrote:
> Is the triggering incident not just another cautionary note that we learn > from? That was my original thought. I don't mean my thought has changed, but that's the reason I bothered to raise this. > Why is this particular incident a sign that we need to change the protocol > when so many others have not been? I mentioned this only in an early private, off-list reply and it deserves to be said here - I'm not advocating for changing anything. As it is, colliding key tags is at worst a rare snag in operations. When I say I've seen it three times over 13 years of observations, I mean to stress that it is a rare event, and that only once has it "hit the press", it isn't usually (2 out of 3) operationally impacting. I don't think anything seen so far justifies altering past definitions. However...for any future re-designs I'd keep this tale in mind. If I had a time machine, I'd go back 25-30 years and argue against the 16-bit field. I.e., when looking at DELEG or anything DELEG may enable down the road, I'd side away from the use of "pointers" like key tags or possibly hashes. A side note: there is something I'm working on (which may never see the light of day) where I considered using a hash to identify a long-lived key. Then I realized that if hash algorithms are changed, it would be impossible to tell if the old hash and the new hash indicated the same key. Not a key collision issue, the fact that hashes are one-way mean that you can't tell, from two different hash values, each of a different hash algorithm, if they refer to the same (public) key - unless you have the (public) key itself. And in my situation, having to have the key to do this negates the benefit of passing a (shortened) hash value around. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
