[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC

[John Levine <[e-mail]>]

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 <[e-mail]> wrote:
>On Thu, Jul 25, 2024 at 5:44 PM Paul Hoffman <[e-mail]>
>wrote:
>
>> On Jul 25, 2024, at 17:34, Shumon Huque <[e-mail]> 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.