On 2/14/24, 10:10, "DNSOP on behalf of Paul Hoffman" <dnsop-boun...@ietf.org
on behalf of paul.hoff...@icann.org> wrote:
> On Feb 14, 2024, at 01:39, Petr Špaček <pspa...@isc.org> wrote:
> > In my mind this is good enough reason to outlaw keytag collisions -
> without them it would be _much_ easier to implement reasonable limits without
> risk of breaking legitimate clients.
>
> Outlawing keytag collisions implies that the signer has to keep a copy of
> every keytag they've ever emitted. Adding that requirement nearly 20 years
> after the RFCs were finished is incredibly unlikely to work universally, so
> validators could not rely on it. Why add a requirement that cannot be relied
> on?
The requirement could cover only currently published keys - but then there is a
risk that a cache somewhere has a copy of a now-unpublished key what collides
with a now-published key. You'd not need all key tags, just recent ones.
('Recent' is a relative term I'll leave undefined.)
The fact that 20 years has passed points out to the emerging nature of the
field of operations. This situation is based on probability, and only as time
passes does the probability grow to the point where any problem is noticed.
There are lots of analogous situations where, in early years the lack of
participants meant interactions were rare and thus didn't need a thick set of
rules, but as barriers to entry dropped the crush of new participants called
for more stricter rules of order. I see that it is inevitable that the passage
of time will cause changes to the old rules - when needed. (And to stress this
again - the key tag situation is not one where I'd advocate for making changes,
just noting that I wouldn't recommend anyone design thisway again.)
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
