On Feb 20, 2024, at 5:42 AM, Edward Lewis <[email protected]> wrote: > > On 2/16/24, 15:05, "DNSOP on behalf of Mark Andrews" <[email protected] > on behalf of [email protected]> wrote: > > Pardon ... perhaps this issue has died down, but I've been off a few days, > and I just saw this... > >> Generating a new key is not hard to do. > > That's not the issue, it's knowing that it would be the wise thing to do that > is the issue. > >> Adding a check against the common key store is not hard to do in a >> multi-signer scenario. It can be completely automated. > > I'm not in agreement with that. Some keys are managed with off-net HSM > devices, accessed only during a key ceremony. There may be some cases where > the key set is assembled and signed without access of the 'net. This is a > result of an early design rule in DNSSEC, we had to design around a system > that air-gapped the private keys from the open network. > > This does underscore the importance of coherency in the key set even in a > multi-signer scenario. (There was talk of trying to let each server have its > own key set perspective.) In order to detect key tag collisions, the > managing entity has to be able to see the entire set. > >> We could even use the DNS and UPDATE to do that. Records with tuples of >> algorithm, tag and operator. Grab the current RRset. Add it as a >> prerequisite with a update for the new tag. > > This approach leaves open a race condition. It's possible that two signers > simultaneously generate keys with colliding key tags and each gets to add > because they don't see each other. My point, while this is admirable, > achieving the perfect solution is out of reach, so let's not assume we can > ever totally avoid key tag collisions.
This isn’t correct, as updates and their prerequisites are applied atomically. If two clients both generate keys with the same key tag, retrieve the existing key set without any keys having that tag, and send updates with the same prerequisites, only the one processed first will succeed. The other will fail the prerequisite check, as the key sets don’t match. Brian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
