Hi all,
let me speak up as an open-source authoritative server (Knot DNS)
implementer.
Since long time, we do care when generating keys to avoid keytag
conflict. Yes, this was motivated purely by easing key management.
However, in the Offline KSK and multi-signer scenarios, keytag conflicts
can still appear. Each co-signer generates their own keys (usually even
in advance) and there is hardly any way how to synchronize it. And no,
they are usually not pipelined in the way that the second co-signer
would see the first one's results first.
One solution that came to my mind would be if the co-signers are
implemented and carefully configured in the way that one produces e.g.
only even keytags and the other one only odd keytags. Or modulo
something for more co-signers. I'm just afraid that resolver caches
might make the final solution more challenging, needing to consider
deleted keys which have still some TTL to go...
This is of course not yet implemented anywhere, so we can't outlaw
keytag conflicts now. We can implement this first in all mainstream
signing software, then politely ask the rest of the world with a help of
some new RFC, and only after that, arrive with a flag day...
I'd like to warn about mis-interpreting the (useful!) mentioned
research. Yes, there are just 200 or so tiny little zones that are
currently experiencing a keytag conflict. However, there are plenty more
and really important zones out there that use signing software and setup
which can generate a keytag conflict at any second, possibly tomorrow. I
beg please don't in any way consider outlawing keytag conflicts in any
near future, this would create a hard-to-grasp sneaky danger all around DNS.
Another warning that I have is regarding to simple thoughts like "if the
resolver sees a keytag conflict, then it shoud XY" (go insecure, go
bogus, flush cache...). Isn't is possible that an attacker may inject a
malicious answer packet containing a keytag conflict? In the case of the
first DNSKEY query, the RRSIG doesn't have to fit, since the resolver is
just receiving the KSK in that same packet. I mean, the resolver can
only really be sure that there is (or isn't) a keytag conflict once it
has already validated the DNSKEY RRSet!
Anyway, it is interesting to see how keytags are transitioning from
being a probabilistic heuristic to something the resolvers want to rely
on, and want it to be reliable and unambiguous. And it's funny how at
the same time, there were ideas of abandoning keytags whatsoever.
I'm not really a "resolver guy". What I think the resolvers should do is
to somehow limit the very general amount of work per each domain, no
matter if the amount is caused by keytag conflict, excessive NSEC3
iteration count, long CNAME chains, expensive signing algorithm,
whatever. But I'd be still happy if the resolvers impose a limit of
conflicting keys, to be like 3 or 4.
Thanks for reading!
Libor
And no, the pipeline doesn't go the way that one co-signer signs "Dne
14. 02. 24 v 10:39 Petr Špaček napsal(a):
On 14. 02. 24 2:57, Mark Andrews wrote:
On 13 Feb 2024, at 00:56, Edward Lewis <edward.le...@icann.org> wrote:
On 2/9/24, 22:05, "Mark Andrews" <ma...@isc.org> wrote:
The primary use of the key tag is to select the correct key to
validate the signature from multiple keys.
Yes - which is great if 1) you need to pare down the potential set
of keys into something you can handle (like, from 10's to 3) and 2)
if you have somewhat to request only those keys.
Operators generally only publish 2 keys outside of rolls, 3 when
rolling the ZSK or the KSK, maybe more if they aren't optimizing.
There's no need to specify a subset. I say this with complete
highsight.
I would still argue that there is still a need even if there is only
2 keys. Verification is expensive. It always has been.
I think CVE-2023-50387 listed on
https://www.nlnetlabs.nl/projects/unbound/security-advisories/
is nice demonstration how dangerous it can be when resolver has to
implement try-and-see approach.
In my mind this is good enough reason to outlaw keytag collisions -
without them it would be _much_ easier to implement reasonable limits
without risk of breaking legitimate clients.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
