Re: [DNSOP] [Ext] About key tags

Hi all, let me speak up as an open-source authoritative server (Knot DNS) implementer. Since long time, we do care when generating keys to avoid keytag conflict. Yes, this was motivated purely by easing key management. However, in the Offline KSK and multi-signer scenarios, keytag conflicts

Re: [DNSOP] [Ext] About key tags

On 2/15/24, 13:03, "DNSOP on behalf of Ralf Weber" wrote: >... key collisions should not be allowed. The problem with this statement is that you can't prevent them in advance. So long as we have a short-hand means for referring to a key, you run this risk. And if someone sees an advantage in

Re: [DNSOP] [Ext] About key tags

> On 16 Feb 2024, at 12:35, Edward Lewis wrote: > > The potential for abuse does exist, but the potential isn't addressed by > documenting "key collisions should not allowed." Indeed. > I do agree that key collisions should be avoided, for the sake of key > management, but given the diffic

Re: [DNSOP] [Ext] About key tags

On Thu, Feb 15, 2024 at 4:37 AM Petr Špaček 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. >

Re: [DNSOP] [Ext] About key tags

Hi Jim, On 16 Feb 2024, at 14:50, Jim Reid 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 > whenev

Re: [DNSOP] [Ext] About key tags

On 16. 02. 24 16:19, Joe Abley wrote: Hi Jim, On 16 Feb 2024, at 14:50, Jim Reid 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 o

Re: [DNSOP] [Ext] About key tags

On Feb 16, 2024, at 08:12, Petr Špaček wrote: > > 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

Re: [DNSOP] [Ext] About key tags

> On 16 Feb 2024, at 15:19, Joe Abley wrote: > > 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 part

Re: [DNSOP] [Ext] About key tags

> On 16 Feb 2024, at 16:17, Paul Hoffman wrote: > > I keep hoping that this group will focus more on those who go through the > effort to sign their zones than those who write the software. Hmmm. If it wasn’t for those who write the software, there would be nothing for those who sign their z

[DNSOP] work limits - RFC 4035 section 5.3.3

Hello, let me start a new thread because the "About key tags" is getting out of hand. Intro = The so-called KeyTrap CVE has technical report available here: https://www.athene-center.de/fileadmin/content/PDF/Keytrap_2401.pdf TL;DR is: RFC 4035 section 5.3.3. Checking the Signature has a

[DNSOP] work limits - RFC 5155 section 8.3 (NSEC3 closest encloser proof)

Hi again, this thread is NOT related to KeyTrap CVE. This thread focuses on CVE-2023-50868 "NSEC3 closest encloser proof can exhaust CPU" and lack of caveat about work limits in RFC 5155 section 8.3. Please note this attack is not described in the KeyTrap technical paper linked in the other

Re: [DNSOP] [Ext] About key tags

On 16. 02. 24 15:51, Shumon Huque wrote: On Thu, Feb 15, 2024 at 4:37 AM Petr Špaček > 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 failur

[DNSOP] KeyTrap Algorithmic Complexity Attacks Exploit Fundamental Design Flaw in DNSSEC

Dear members of the DNSop wg, In the recent years we have been working on DNSSEC and mitigated a number of vulnerabilities. Last year we identified flaws in the DNSSEC standard that can be exploited to launch Denial of Service attacks against DNSSEC validating software. For instance, some popular

Re: [DNSOP] [Ext] About key tags

On Fri, Feb 16, 2024 at 12:17 PM Petr Špaček wrote: > On 16. 02. 24 15:51, Shumon Huque wrote: > > On Thu, Feb 15, 2024 at 4:37 AM Petr Špaček > > wrote: > > > > On 14. 02. 24 16:45, Shumon Huque wrote: > > > > > > What colliding keytag limits are other reso

[DNSOP] On suffering ... Re: [Ext] About key tags

On 2/16/24, 11:13, "DNSOP on behalf of Petr Špaček" wrote: > should resolvers suffer from more complex code & work, or should signers > suffer if they do something very unusual? Coming from this perspective, find a solution may be difficult. At the core, the DNS is extremely flexible, overly so

Re: [DNSOP] [Ext] About key tags

On Feb 16, 2024, at 12:17, Petr Špaček wrote: > >  > 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 > allowe

Re: [DNSOP] [Ext] About key tags

The problem with key tag collisions is that you turn verify operations from 1 per RRset to 1.5 per RRset for a two RRSIGS with the same tag and algorithm. You can figure out the average number of verify operations with 3, 4 etc. Those extra verify operations are completely avoidable by rejecti

Re: [DNSOP] work limits - RFC 4035 section 5.3.3

It appears that Petr � pa� ek said: >TL;DR is: > >RFC 4035 section 5.3.3. Checking the Signature >has a MUST loop doing crypto operations over product of #DNSKEY * #RRSIG >set (for matching key tags), and this can be damn expensive. > >Of course we should have listened to RFC 1034 page 35 "limit

Re: [DNSOP] [Ext] About key tags

Yeah, regardless of whether the protocol allows it, I would not want colliding keytags in any zones that I operate. Just so that answers can be accepted without any unnecessary signature verification operations. I've made a note to describe a procedure to avoid colliding keytags in rfc8901-bis (if