I am a bad person. My zone uses the new algorithm and I put in two keys with the same tag. Now what? Other than perhaps stopping at two keys rather than three, what is the difference in what resolvers do?
Get BlueMail for Android On Jul 25, 2024, 19:54, at 19:54, Shumon Huque <shu...@gmail.com> wrote: >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
