On Wed, Feb 28, 2024 at 3:59 PM Edward Lewis <edward.le...@icann.org> wrote:
> On 2/27/24, 17:09, "DNSOP on behalf of John Levine" <
> dnsop-boun...@ietf.org on behalf of jo...@taugh.com> wrote:
>
> > The kind of load is different but in each case the client needs to
> > limit the amount of work it's willing to do. We can forbid it in the
> > protocol but unless you have better contacts at the Protocol Police
> > than I do, people will do it anyway.
>
> I side with John Levine's line of reasoning, that the solution is
> defending against taking on too much work (in this case, the validator caps
> it's effort - in whatever way is appropriate). It would be futile to
> prevent key tag collisions from happening via a protocol change as a
> malicious actor is not bounded by specifications.
>
> If it is forbidden in the protocol, it might still happen.
>
Yeah, as you might guess from my past messages on this thread, I am of the
same opinion. There is a general principle about limiting work that
resolvers need to follow, and this recent attack (like many others before
it) exploited resolvers that failed to sensibly do that. The novel thing in
KeyTrap is that it exploited a failure to bound cryptographic work, but the
same principle applies.
Here's my minor restatement of the resolver's top priority from RFC 1034:
Bound the amount of work (e.g. packets sent, parallel processes
started, computations performed, time spent) so that a request
can't get into an infinite loop, start off a chain reaction or
unreasonably lengthy sequence of tasks, requests or queries,
EVEN IF SOMEONE HAS INCORRECTLY OR MALICIOUSLY
CONFIGURED SOME DATA.
In the parenthetical examples of bounding work, I've added "computations
performed" and "time spent".
And in the uppercased "EVEN IF" phrase, I've added "MALICIOUS CONFIGURED".
I think the specific case of keytag collisions does deserve some special
thought though. Even if resolvers limit the number of collisions, it's in a
zone owner's interest to not have them at all. Colliding keytags in the
DNSKEY RRset means imposing additional unnecessary signature verification
work on resolvers for verifying every signed RRset in the response. And for
efficiency reasons, a zone owner should want to have their answers accepted
by validating resolvers with the minimum amount of work (and no unnecessary
work).
Banning keytag collisions outright today would not be a good idea - we risk
rendering some sights unresolvable through no fault of their own. DNSSEC
already has plenty of detractors, and we don't want to give them more
ammunition by creating problems in the ecosystem that can be easily
avoided. 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).
Shumon.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
