On Fri, Feb 16, 2024 at 12:17 PM Petr Špaček <pspa...@isc.org> wrote:
> On 16. 02. 24 15:51, Shumon Huque wrote: > > On Thu, Feb 15, 2024 at 4:37 AM Petr Špaček <pspa...@isc.org > > <mailto:pspa...@isc.org>> wrote: > > > > On 14. 02. 24 16:45, Shumon Huque wrote: > > > > > > What colliding keytag limits are other resolver implementers > placing? > > > > Right now BIND tolerates 1 validation failure before hard-failing. > This > > counter is not limited to colliding key tags. > > > > > > You didn't quite answer my specific question - does BIND now have a > > limit on keytag collisions, and if so, what is it? > > It does not handle collisions in any special way. It simply does not > validate and the resolver has no way to tell if the crypto thingy is > wrong or if it just tried a wrong key. Any such failure is counted > towards fail-budget (1 allowed). > Thanks for the clarification! > > For your more general answer, I want to make sure I clearly understand > > what you are saying. > > > > Does "hard-failing" mean blacklisting only the authoritative server that > > gave the bad response that caused any validation failure, and re-trying > > other available servers for the zone (to some limit)? > > Hard-failure is probably a wrong term, sorry about that. Reaching either > limit stops the current validation attempt and treats that specific > answer as bogus. All the rest (retries, caching and whatnot) is the same > as it was. > That's reassuring! For a moment there, I was contemplating whether I needed to tell our Ops team to start planning to switch our resolver infrastructure to Unbound or something else ! :) > > Resolvers need to have robust re-try behavior in the face of attacks (or > > misconfigurations, or unavailability). This all of course has to be > > balanced with the requirement to bound the amount of work (but as I > > pointed out in my earlier email, this was known in 1987, though > > implementers seem to have forgotten that fundamental principle > sometimes). > > Oh yes, and that advice is forgotten about way more often than in this > single case. See (definitely incomplete) list here: > https://www.isc.org/blogs/2024-bind-security-release/ > > Based on the list above I claim that statement "KeyTrap vulnerabilities > are fundamental" is either nonsense OR we have to declare all the other > vulnerabilities "fundamental" as well ... > I agree. I would suggest that these vulnerabilities are fundamental to many "implementations" of resolvers. Not to the DNS protocol itself. The base specification has already advised implementers to sensibly bound work. I also don't think we need to arduously spell out limits for each individual protocol element. Furthermore, any specific limits we suggest will likely become out of date over time as processing power increases. We could instead add language more generally around the principle of limiting work. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
