On 2/15/24, 13:03, "DNSOP on behalf of Ralf Weber" <dnsop-boun...@ietf.org on behalf of d...@fl1ger.de> 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 having a collision, they will hand-craft the situation. One might think, but this is crypto, it's hard to craft collisions for hash functions (stepping away from the simple to collide 16-bit field key tag field). But a malicious actor doesn't need the crypto to work, they just need it to cause you to react (and chew up your resources). So, collisions might happen on-demand. We have the notion of a time out in the query-response exchange. If we didn't, it would be possible to claim name servers that are not reachable and have resolvers waste time and resources waiting for responses that will never come. The same notion ought to be applied to validation - set a time limit. This would penalize those with overly complex (but honest) configurations and cap the damage malicious actors can cause. This approach is also neutral to how the complexity has come about, key tag collisions are not the only nor are they really the culprit here. A few key tag collisions have been observed, probabilistically there have been more, for the most part no widespread damage. The potential for abuse does exist, but the potential isn't addressed by documenting "key collisions should not allowed." I do agree that key collisions should be avoided, for the sake of key management, but given the difficulty in avoiding them in all cases, I can't see that a protocol action can be taken to rule them out. And there will always be non-compliant malicious-intent code available to cause collisions if collisions are indeed desired for abusive reasons. The solution here is to roll out the notion across implementations that it is acceptable for a validator to fail a data set's DNSSEC validation based on time/computational complexity. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
