On Sat, Mar 2, 2024 at 3:57 PM Peter Thomassen <[email protected]> wrote:
> > On 3/1/24 14:44, Philip Homburg wrote: > >> Seriously, while I do believe in the need for a coherent DNSKEY > >> resource record set, there are some multi-signer proposals that do > >> not. If the key set has to be coherent, then someone can guard > >> against two keys being published with the same key tag. The recovery > >> may not be easy as you'd have to determine what key needs to be > >> kicked and who does it and where (physically in HSMs or process-wise). > >> I have some doubt that key tag collisions can be entirely avoided. > > > > So now we moved the problem away from the core DNSSEC protocols to the > > realm of multi signer protocols. > > The core DNSSEC protocol includes multi-signer. RFC 8901 just spells out > explicitly how it is covered by the protocol; that's why its status is > Informational. > Yes, 8901 was not considered to be a change to the protocol, but an operational model that accommodated multiple signers. There was some discussion about whether it should be a "BCP", but the consensus during its development was that we might do that at a later time once more operational experience in the field was gained with it. > The first step to conclude is that for the core DNSSEC protocol, requiring > > unique key tags is doable. > > No. There is no core and non-core part of the spec. Support for multiple > keys, including keytag collisions, simply is part of that protocol. > Yes, I agree. (Banning keytag collisions, if we are proposing that, is a protocol change.) Not also that DNSKEY set "coherency" is not really the issue. Even for a single signer they may be temporarily incoherent across nameservers because of normal change propagation delay. Multi-signer operations (for steady state or for a transitional state needed for DNS operator changes) can extend that period substantially. Collision avoidance is about the key generation process and the set of entities involved. Shumon.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
