Re: [DNSOP] [Ext] About key tags

[Shumon Huque <[e-mail]>]

On Mon, Mar 4, 2024 at 3:29 AM Philip Homburg <[e-mail]>
wrote:

>
> What I mean is that if we take all of the standards track DNSSEC RFCs and
> we
> add a new RFC that says something to the effect:
> 1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key
>    tags.
> 2) An authoritative DNS server MUST not serve a set of RRSIG records that
>    corresponds to a single RRset where the collection of RRSIG records has
> a
>    duplicate key tag.
>
> then as far as I can tell, there is no conflict with currently published
> standards track DNSSEC RFCs.
>
> In addition for most signers and authoritative servers it will be easy to
> meet
> those requirements and many signers are already in line with those
> requirements.
>
> The only thing that prevents us from publishing such an update is an
> informational RFC about multi-signers (or other practices that are not
> documented or standardized within the IETF).


Note that RFC 8901 is an IETF consensus document that was produced in the
DNS Operations working group. So, we can't just dismiss it and propose
protocol changes without considering effects on that (and other documents).
As I also noted earlier, its status will likely be upgraded when we revise
it.

Furthermore, it is not as some have previously tried to characterize it, a
niche
configuration that only a few large enterprises will use. Multi-signer is a
key
enabler of non-disruptive transfers of signed zones across distinct
providers.
There is a currently adopted working group document (intended category:
Standards Track) that is laying out the details of that process:

    https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-automation/

Here's a presentation from Christian Elmerot, of a real world example of
a recent successful multi-signer transition (.GOV from Verisign to
Cloudflare):

https://indico.dns-oarc.net/event/48/contributions/1038/attachments/1005/1948/gov-transition-nsec-nsec3.pdf

Some (single) organizations are also looking at multi-signer techniques
for deployments across distinct HSM vendors.

Separately from multi-signer, I agree with John Levine's comments about
not breaking existing configurations that are deployed in the field.

Shumon.