Hi, On 7/30/24 09:41, libor.peltan wrote:
1) I'd very much like to see more exact guidance of how the auth server / signer should prevent keytag collisions. For example, what our Knot DNS does is: (a) on a signle signer, when newly generated key causes collision, discard it and generate another; (b) in multi-signer (or offline-KSK) operation, fragment the keytag space between key generators (e.g. first signer discards any generated key with even keytags, the other one with odd ones). What I'm missing is a reasearch confirming (or rejecting) that this both is always possible -- i.e. that with existing (and future?) algorithms, it can't happen that the key tags would be always following a pattern (like being even all the time), putting the key generator in a hopeless loop.
I would say that general guidance / research is impossible, as the answer depends on the internal structure of the DNSKEY RDATA for algorithms that might be defined in the future, and that stuff is unknown. It's seems conceivable that some future (or private/experimental) algorithm's DNSKEY RDATA might have correlated least significant bits in its odd octets (which would translate into a bias towards even/odd key tags). Given that the key tag algorithm clearly is very biased and potentially exploits DNSKEY RDATA structure [1], it may be worth replacing it with another calculation rule (for new algorithms only). Slides 20-22 of [1] mention CRC16 as one candidate; perhaps an even less biased hash function would be better. While collision probability would not be significantly reduced (due to the birthday paradox), it at least would allow strategies like Libor's partitioning the key tag space by operator. Best, Peter [1]: Slides 10, 11 https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
