On Tue, 15 Jul 2025, Philip Homburg wrote:
Colliding with what? Just the other keys it is writing at the time?
On a multi-signer setup it can collide and its not your own other keys
writing at the same time.
Looking at it from a validator perspective, collisions can affect validation
in two major ways:
1) There are two (or more) keys in a DNSSEC RRset that match a DS record in the
parent zone. This one is realively cheap, just a hash calculation.
Yes.
2) There are two (or more) keys in a DNSSEC RRset that match an RRSIG record.
This is the expensive part.
This is not expensive. It is still cheap with the limit or 2 or 3
failures allowed. I mean, compare this to do doing DoH to all auth
servers, this crypto operation amounts to nothing.
So in short a DNSSEC RRset must not contain keys that have the same key tag
(and the same algorithm).
This arguments hangs on the "expensive" part, which is not actually
expensive.
There are some exceptional condations that need to be taken into account.
In a double signature ZSK roll, it is possible that the old and the new
ZSK have the same key tag but never appear in the same DNSKEY RRset. So
it would be good to prohibit a collision in this case as well.
It is not "good" to prohibit things that may happen. Sure, you can say
they violated the RFC, but it is still an outage.
Ultimately, what validators need is a low limit on the number of
signature validations that are allowed to fail. Collisions are obviously an
issue, but there might be other parts of the protocol or operational
pratices the cause problems.
Exactly. collisions don't need to be handled, tracker, or have
complicated exception code written for them. Just count the numbers
of validation failures in the chain.
It is easy for this group to come up with more MUST NOTs about
things we forgot in the past, knowing that they will not be
implemented. It is harder (but maybe better) for us to simply
describe the situation and how we got here.
We have collisions. We got there because it takes effort to avoid them and
there is no requirement to avoid them.
And requirements to avoid them will be very hard with multi-signer, and
as indicated above, you still need to write code to bail on too many
signature validation failures, so the best course of action is to do
nothing to the protocol.
How does this description help validators?
Helping a common implementation mistake by writing an informational
document can be useful. Whether we need one regarding keytags and
validation failures to avoid DoS attacks is up for debate. I think
there is little point now as all the major implementations already
do this and new implementations failing badly can see why the main
implementations are not vulnerable and learn pretty quickly.
(and also, new implementers are more likely to not read a bunch of
RFCs because they "know better", see for example systemd-resolved)
I'm not opposed to documenting this in an RFC, but I'd prefer the WG
to spend time on other things instead.
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
