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]<https://urldefense.com/v3/__http:/fugue.com__;!!PtGJab4!52sLdAP9_ILh2m4N5k6puN4H9Muh5caOPGzze8vHKdSPc_3Kk48D2xgluq5vE9VesRqSm1Hbnpk8sfr1PuR_81s$>, > that fugue.com >[fugue.com]<https://urldefense.com/v3/__http:/fugue.com__;!!PtGJab4!52sLdAP9_ILh2m4N5k6puN4H9Muh5caOPGzze8vHKdSPc_3Kk48D2xgluq5vE9VesRqSm1Hbnpk8sfr1PuR_81s$> > 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
