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).
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.
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 ...
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
