> On 29 Feb 2024, at 08:22, Shumon Huque <shu...@gmail.com> wrote: > > 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.
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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
