On 16. 02. 24 16:19, Joe Abley wrote:
Hi Jim,
On 16 Feb 2024, at 14:50, Jim Reid <j...@rfc1035.com> wrote:
The latest patches to mitigate the keytrap vulnerability are welcome and much
appreciated. Though IMO they’re a short-term fix. A long-term solution would be
implementation guidelines as outlined above or to hard-fail validation whenever
there’s a key tag collision.
I'm not sure why this is true.
Resolvers are routinely managed in order to safeguard local resources, harden
themselves against attacks, etc. Not every query gets answered. Seems to me
that limiting the time a validating resolver spends churning its organs over a
particular RRSIG and causing it to fail to validate if the indigestion gets too
bad is just another example of sensible local policy.
While I think some centralised guidance about how to harden your resolver against this
attack (or any attack) is useful (and similarly guidance to avoid duplicate key tags
seems like a great idea for signers) I am struggling to see any of this as a problem with
the protocol or a fundamental weakness in DNSSEC that needs a "long-term
solution".
If a zone's signatures and keys are constructed and published in such a way
that it causes indigestion in validators, and as a consequence validators fail
to return responses for data in that zone, that's a self-inflicted problem and
the zone administrator surely has every incentive to fix the problem. If the
tools the zone administrator is using make the problem hard to make, then so
much the better.
The DNS is filled with misconfigurations and junk. Things get fixed if they
need to when things break. Sometimes things break in painful ways and so we
make changes to mitigate or avoid the pain. How is this not just another day on
the Internet?
I think you describe it accurately, but people who implement resolvers
in this thread (me, Ralf, Brian W.) apparently disagree where the pain
should land - should resolvers suffer from more complex code & work, or
should signers suffer if they do something very unusual?
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
