I also support adoption.
On Mon, 17 Aug 2026, 02:50 Paul Wouters, <[email protected]> wrote: > > 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] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
