Re: [DNSOP] [Ext] About key tags

[Mark Andrews <[e-mail]>]

> On 29 Feb 2024, at 08:22, Shumon Huque <[e-mail]> wrote:
> 
> On Wed, Feb 28, 2024 at 3:59 PM Edward Lewis <[e-mail]> wrote:
> On 2/27/24, 17:09, "DNSOP on behalf of John Levine" <[e-mail] on behalf of [e-mail]> 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.

Sorry this is fuzzy reasoning.  A BCP will never get to the state where the validator can actually stop on a single error.  The ONLY way to do that is to update the protocol and then wait a while before relying on the new rules in the validator.

We did this with EDNS (RFC 6891, April 2013) when we tightened up the unknown option behaviour (unspecified -> specified).  The hardest part is getting vendors to fix their products.  That was the most important work in 2019.  After that there was a very rapid reduction in broken servers out there.  It is not impossible to do.

Mark

> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]