On 14. 02. 24 15:49, Shumon Huque wrote:
On Wed, Feb 14, 2024 at 8:54 AM Petr Špaček <pspa...@isc.org
<mailto:pspa...@isc.org>> wrote:
On 14. 02. 24 14:37, Joe Abley wrote:
> Op 14 feb 2024 om 13:46 heeft Edward Lewis
<edward.le...@icann.org <mailto:edward.le...@icann.org>> het
volgende geschreven:
>
>> On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček"
<dnsop-boun...@ietf.org <mailto:dnsop-boun...@ietf.org> on behalf of
pspa...@isc.org <mailto: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.
>>
>> That would make key tags meaningful. ;--)
>>
>> The question is how, in a multi-signer friendly way.
>
> To be honest it feels like there as many opportunities for
accidents by imposing restrictions on publishing duplicate keytags
as there are by consuming them. Your text summarised a few of them
quite nicely, Ed, without even considering the new opportunities for
failure due to the interplay between systems following any new rules
that might be imposed and those that don't.
>
> Is the triggering incident not just another cautionary note that
we learn from?
>
> Why is this particular incident a sign that we need to change the
protocol when so many others have not been?
>
> These seem like questions that deserve convincing answers before
jumping ahead to how a new restriction might be structured.
Let me turn the question around:
How many keytag collisions are you willing to allow & at the same time
protect validators from 2023-50387?
Does the KeyTrap vulnerability exploit colliding keytags? The paper
isn't public yet and the CVE does not mention this.
Obviously, resolvers need to sensibly bound the work they are willing to
do to resolve queries, especially so in the face of misconfigurations
(or malicious configurations). And that basic principle should apply to
keytag collisions too.
In fact, bounding work is the documented top priority of a resolver from
RFC 1034 (published 1987).
"The recommended priorities for the resolver designer are:
1. Bound the amount of work (packets sent, parallel processes
started) so that a request can't get into an infinite loop or
start off a chain reaction of requests or queries with other
implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
SOME DATA.
..."
(My usual addendum to this paragraph is that the resolver should also
bound the time spent too).
Oh yes, this is basically what
https://www.isc.org/blogs/2024-bind-security-release/
tries to explain at length.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
