Re: [DNSOP] [Ext] About key tags

[Philip Homburg <[e-mail]>]

>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.

Under the assumption that adding a constraint for unique key tags for the
DNSSEC standard protocols is relatively easy (from a protocol point
of view, getting changes deployed is always a lot harder), we can
take a look at RFC 8901. As you say it likely needs a revision anyhow.

So, for example Section 6.1 of RFC 8901.

For a KSK rollover, the zone owner would generate a new KSK. The zone owner
also signs the DNSKEY RRset. So this is essentially the same as what any
other signer would have to do. No real changes are required except making
sure to select a new KSK with a key tag that does not conflict with
keys already in the DNSKEY RRset.

Then for a ZSK rollover. Each provider has independent signing keys, so a
provider would have to select a new signing key that does not conflict
with current keys in the DNSKEY RRset. Again, this is what any signer would
do in the new model.

Then the provider would submit the new key to the zone owner for inclusion
in the DNSKEY RRset. At this point, if two providers would want to update
their keys at the same time and happen to have new keys with conflicting
key tags, we would have a problem.

However, this can only happen if two ZSK rollovers would happen at the same
time. Which is something that can be consideren bad operational practice
and is certainly not suggested as something to do in Section 6.1. Furthermore,
Section 6.1 is explicit about the coordination between providers and the
zone owner when it comes to a ZSK rollover. So it is easy for a zone owner
to prevent two ZSK rollovers at the same time.

I have to admit, model 2 would be a bit more complex. But not fundamentally
impossible.