> On 21 Feb 2024, at 01:58, Edward Lewis <edward.le...@icann.org> wrote: > > That’s where I’m heading as well… > 1) Benign collisions aren’t major headaches, except perhaps for the key > manager (because rare events are headaches) > 2) Validator resource consumption is a general issue, not tied to key tag > collisions
Validator resource consumption (CPU) *is* is tied to tags. Without tags the cost of verification increases and the number of cache misses that can be handled decreases as the number of keys per algorithm increase. A tag collisions undoes the value of the tag for the keys that collide. 1 -> 1 2 -> 1.5 3 -> 2 4 -> 2.5 > My kicking this off was not the KeyTrap issue, a report of a potential > maliciously abused vulnerability. My kickoff was the report that a TLD “went > down in DNSSEC” because they published the wrong key in a key tag collision > set. That’s why I keep raising the key management angle. > From: Ted Lemon <mel...@fugue.com> > Date: Tuesday, February 20, 2024 at 09:48 > To: Edward Lewis <edward.le...@icann.org> > Cc: Mark Andrews <ma...@isc.org>, Paul Wouters <p...@nohats.ca>, > "dnsop@ietf.org" <dnsop@ietf.org> > Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] > About key tags > Sorry, I did not mean that the attack isn't a serious problem. I mean that > insisting that there be no key hash collisions in a verification attempt is > not as hard a problem as you were suggesting. The main issue is that it would > require a flag day, but the number of affected zones in the wild is probably > small enough that this could be managed. My point was that the keying and > signing of large, sensitive zones should not be an impediment to having it be > the rule that key hash collisions aren't allowed. Like, I'm not saying there > aren't problems, but this is not an insurmountable problem. > On Tue, Feb 20, 2024 at 9:41 AM Edward Lewis <edward.le...@icann.org> wrote: >> >> >> From: Ted Lemon <mel...@fugue.com> >> Date: Tuesday, February 20, 2024 at 09:05 >> To: Edward Lewis <edward.le...@icann.org> >> Cc: Mark Andrews <ma...@isc.org>, Paul Wouters <p...@nohats.ca>, >> "dnsop@ietf.org" <dnsop@ietf.org> >> Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] >> About key tags >> >This seems like an implementation detail. >> I don’t want to brush this off that quickly. >> >The random likelihood of the root and com key hashes colliding seems >> pretty small. >> This is very true - in nature. The scare raise here is that someone may >> intentionally concoct a situation, intending to cause havoc. I do have a >> dose of skepticism when use case is discovered academically as opposed to >> being seen in operational packet flows, but that doesn’t mean the >> vulnerability is irrelevant. Probably there are lots of holes remaining in >> the protocol design, not yet discovered, so long as they aren’t being they >> aren’t operationally impactful. >> The KeyTrap issue is resource consumption/depletion attack and it mentions >> key tag collisions as an ingredient, which is driving the urgency of this >> discussion. My read of the paper is that, at heart, this is a general >> resource exhaustion problem which stems from the agility of the DNS protocol >> to find an answer no matter how hard it is to find. Key tag collisions help >> in hiding intent of a malicious configuration by lowering the number of >> signature records needed. >> >And while com is rather large, computes aren't as expensive as they were >> when y'all invented the ritual. I suspect that if you just always pick two >> keys and sign the zones twice, this problem becomes so improbable that we >> never have to fall back to actually re-doing the ceremony. But if we did >> have to fall back once in a blue moon and re-do the ceremony, that might be >> quite a bit cheaper than allowing key hash collisions in situations where >> it's actually a problem. I think it would be completely reasonable to insist >> that if there is a key collision between e.g. com and fugue.com [fugue.com], >> that fugue.com [fugue.com] could be obligated to regenerate its key rather >> than com. >> In validation, key tag collisions are a problem when there is malicious >> intent and no more than a nuisance in a benign collision. >> If an operator had two active ZSKs, there would be two signatures and two >> keys. With non-colliding key tags, it would be easier to line them up - and >> recall the rule that it only takes one successful operation to declare >> success. With a collision, there’s a 50% chance of a misalignment at first, >> which is what leads to the 1.5 signature verification operations per >> instance comes from. Given the low probability of a collision (it’s rare!) >> that 1.5 isn’t a big deal. (No one as suggested a 3-key collision, which >> would be rarer, especially as most operators never exceed two keys of the >> same role per DNS security algorithm.) >> Nevertheless, in a malicious case (no more need be said) … this makes me >> think the appropriate solution is for validators implement self-protection >> (timeouts) and not try to avoid collisions. >> ‘Course, collisions still are a problem for the key managers, but that is a >> local problem. Unless they publish the wrong key in the collision set. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
