On 2/14/24, 09:00, "Havard Eidnes" <h...@uninett.no> wrote:
Not arguing, but to tease out the difficulty of all this: >One is to line up the signers "behind each other", so that the second one >signs an already-signed-by-the-first-signer zone... The issue is in deciding the order they are lined up. In one case, I was told a backend was changing, the outgoing created the key that led to the collision. (In this case, the outgoing key never signed data, hence no validation issues were recorded.) The solution was to let this go - the collision causing key was about to be deleted anyway. It's difficult to derive a definitive rule. >Or have I totally misunderstood, and your statement about required time of >enforcement is a universal property of all multi-signer scenarios? I think it is a general protocol design consideration - if you need to communicate a piece of data and require some state be maintained because of it, you have to have some means to enforce the requirement. If we were to require that the key tag point to a unique published key, we'd have to enforce this via a check on the zone's DNSKEY resource record set. Under some visions of multi-signer, different nameservers might publish different information based on the operator. While I don't believe that incoherent versions of the DNSKEY resource record set can co-exist peacefully, it is possible that the RRSIG resource records may differ from source to source. The problem in all this is - when and how could the protocol ensure there is no key tag collision? Or limit the number of keys with matching key tags? Going back a few messages, I raise the key tag issue in the sense of "let's not do this again" and not to try to change what it is now. Clearly, changing it (to avoid collisions) would be difficult. And, given the relative rarity of any problem stemming from it, not worth fixing at this point. Just don't do it again. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
