On Thu, Jul 25, 2024 at 5:44 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Jul 25, 2024, at 17:34, Shumon Huque <shu...@gmail.com> wrote: > > > > Folks, > > > > For discussion ... > > > > Mark Andrews, Elias Heftrig, and I have a new draft on collision free > key tags in DNSSEC. This topic has been in the air since the Keytrap > vulnerability disclosure -- and IETF120 hallway track conversations this > week prompted us to write up a rough initial proposal for this. Will need > much more fleshing out of details etc, but we hope this can serve as a > starting point ... > > > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-keytags-00 [ > datatracker.ietf.org] > > The problems are listed as: > > Colliding key tags impose additional work on a validating resolver, which > then has to check signatures for each of the candidate set of keys > identified by the Key Tag. Furthermore, they open up resolvers to > computational denial of service attacks by adversaries deploying specially > crafted zones with many intentionally colliding key tags [KEYTRAP]. > > The main part of the proposed solution is listed as: > > DNSKEY algorithms MUST have DNSKEY RRsets that do not have colliding key > tags > > There is a mismatch here. If the worry is an attacker creating colliding > key tags to cause more work, that attacker is simply going to ignore the > MUST requirement. > It's a phased mitigation over time. The actual proposal is initially only "new" DNSKEY algorithms will have the no colliding key tags requirement. In which case, yes, the adversary will just use existing algorithms to deploy their attack. Arguably, currently deployed defenses that limit the number of colliding key tags already deal with this. Over time, we could envision requiring this for existing algorithms too, or moving everyone to the new algorithms. Anyway, there is a diverse solution space - we need the community to discuss the various possibilities and hopefully converge. The other goal of course is to make validation more efficient, and avoid resolvers having to unnecessarily check signatures for keys that they don't need to. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
