Re: [DNSOP] [Ext] About key tags

[Shumon Huque <[e-mail]>]

On Sat, Mar 2, 2024 at 3:57 PM Peter Thomassen <[e-mail]> 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.