On Thu, 15 Feb 2024, Ralf Weber wrote:
So to put some real numbers out there. I recently for testing did download all
the zone data I could get from ICANN CZDS and tried to get DNSKEYs for every
domain. So that data set had 256479639 domains (256 million) and out of those
18726163 (18 million or 7.3 percent) actually had DNSKEYs. Out of those 153 had
key collisions which is 0.0008 percent or roughly half of what you expected.
There must be at least one implementation that already was checking for
this then? :) I know at my previous-previous-job our signer code did drop
a clashing keytag during generation to generate a new one. But it only
accounted for a few small TLDs and has since died quietly :)
As for limits, I would say 3 or 4, to account for rare KSK+ZSK keyrollover at
the same time with clashing key tags.
I think 2 is fine as signers also can be updated to generate new keys when they
have collisions
I know they can, and I know that is BCP, but it is not the spec. I don't
think counter-meassures now being implemented should be a breaking
change. If you want a breaking change, write a standards track RFC for
it. (but warning, that would likely see pushback)
but I can see in a multi (dual) signer setup that standby keys could collide
when they made public
If we move towards supporting multi-signer in ways where parties would
not collaborate, then we can't exclude collissions from happening at
all.
Which is why I like unbound's limit of 4. It supports all known valid
(yet unwise) use cases and seems to cap the malicious use cases at a
reasonable workload. No change needed to any RFCs. Has any vendor done
actual attacks on their updated settings and gotten some real world
measurements to help guide this discussion?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
