[DNSOP] Re: Call for adoption: draft-huque-dnsop-multi-alg -rules-08 (Ends 2026-08-31)

I support adoption but hope the document will see a lot of simplication.


On Thu, 13 Aug 2026, Shumon Huque wrote:

> I realize that Mark Andrews is strongly opposed to this draft. But the sense of the authors is that there is a wide group
> of people that agree that the use cases cited are valid (multi-signer and provider transfer across disjoint algorithms,
> pre-publication of trust anchors for algorithm roll, deploying disjoint KSK/ZSK algorithms, selectively returning
> signatures of a specific algorithm, gracefully dealing with mainstream algorithm disablement, etc.), and I hope the working
> group on balance will agree.

I am not really in favour of the generalization in the draft and the
terms UNIVERSAL and FORMERLY-UNIVERSAL. I think the draft can be very
much simplified to state if one of the three algo 9 or 13 or the new
favourite PQC algo validates, that the zone should be considered secure.

I think that would cover the migration case of RSA -> ECDSA, and of
non-PQ -> PQ where one DNS hoster would not support an algo that the
other DNS hoster only supports.

> I am also fairly certain that additional tweaks to the DNSSEC multi-algorithm rules will be needed

To me that sounds like an argumentation to further simplify this draft.

> drafts. For example, algorithm downgrade protection & selective signature delivery for PQC vs classical - a discussion that
> has already started, and folks are thinking about (but we should tackle that separately).

I don't like the mixing of multi-arg scenarios with the DNS hoster migration.

There are two very different things. In multi-arg from a single DNS
hoster, just one algo needs to validate to be secure.  Those not supported
by validators need to fail-open (eg prevent another redhat SHA1 issue,
but I think most resolvers have fixed code for that now).

The DNS hoster migration and no overlapping algo's should also fall
under the "as long as one algo listed in the DS works, it validates".
This allows for either classic + pqc or hybrid signatures, and allows
people to act when progress is made (pqc algo is classically broken,
or CRQC that makes classic unsae) where people can remove the no longer
secure algo set (or stick with the hybrid that would still be secure)

We seem to be making DNSSEC more complex, instead of less complex.

Paul

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]