Hi all,
as an authoritative DNS server (and signer) vendor, let me state my
opinions on this topic and this draft.
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. (We did not go ahead with key brokers
or solving race conditions, as it seemed too much complexity for such a
marginal problem as keytags.)
2) I would still vote for allowing one keytag collision per zone (not
per whole chain-of-trust, like Bind does) instead of none. This would be
more comfortable for many older/simpler signers and not too much
additional work for validating resolvers, IMHO.
3) The idea of imposing the limit at first on new algorithms seems
reasonable -- new algos mean new software which can easily adhere to new
rules. However, we are in the situation that in fact, the existing
resolvers already impose such (or very similar) limits on existing
algorithms. So the document stating the requirement for auths/signer
actually comes retrospectively, and I see no point in using this
conservative enforcement strategy. Anyway, it can realistically take
decades before any new algorithms seize some good portion of DNSSEC. In
other words, that flag day has already silently passed.
4) It would look prettier if the document mentions also rules/preactices
for validating resolvers. Stating what the validator should do (and what
it must not do) when observing a tiny or a huge keytag collision.
5) I agree with Vladimir that keytag collision is just a small piece of
the whole problematic of DNSSEC validator resource consumption. I'm not
sure if it's wise to start with this single piece in one document, or
working on a more covering document, exploring it all. But it's always
useful if we somehow document the limits for signers and validators, so
that they can interoperate smoothly. The goal is to prevent surprises
when the signer signs somehow, and various validators do and don't
validate due to imposing unexpected limits. This is what we should do!
Thank you,
Libor
Dne 26. 07. 24 v 2:34 Shumon Huque napsal(a):
Folks,
For discussion ...
Mark Andrews, Elias Heftrig, and I have a new draft on collision free
key tags in DNSSEC. This topic has been in the air since the Keytrap
vulnerability disclosure -- and IETF120 hallway track conversations
this week prompted us to write up a rough initial proposal for this.
Will need much more fleshing out of details etc, but we hope this can
serve as a starting point ...
https://datatracker.ietf.org/doc/html/draft-huque-dnsop-keytags-00
Shumon, Mark, Elias.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
