> On 14 Aug 2026, at 09:16, Philip Homburg <[email protected]> wrote: > >> This message starts a >> dnsop WG Call for Adoption of: draft-huque-dnsop-multi-alg-rules-08 >> >> This Working Group Call for Adoption ends on 2026-08-31 >> >> Abstract: >> This document restates the requirements on DNSSEC signing and >> validation and makes small adjustments in order to allow for >> more flexible handling of configurations that advertise multiple >> Secure Entry Points (SEP) with different signing algorithms via >> their DS record or trust anchor set. The adjusted rules allow >> both for multi- signer operation and for the transfer of signed >> DNS zones between providers, where the providers support disjoint >> DNSSEC algorithm sets. In addition, the proposal enables >> pre-publication of a trust anchor in preparation for an algorithm >> rollover, such as of the root zone. >> >> This document updates RFCs 4035 and 6840. >> >> Please reply to this message and indicate whether or not you support >> adoption of this Internet-Draft by the dnsop WG. Comments to explain >> your preference are greatly appreciated. Please reply to all >> recipients of this message and include this message in your response. > > I support adoption. As the abstract outlines, this is important to simplify > DNSSEC operation in quite a few cases. > > An issue that may need to be addressed is the desire to strictly prefer > PQC algorithms over traditional ones. That may conflict with the concepts > used in this draft. It would be nice to deal with that in this draft > though it could be addressed later when we create standards for PQC.
I’m a bit wary of the desire to strictly require one algorithm over another when both are present, and I’d like to point to the issues we have had when a set of DS records is present and one uses SHA-256. This has led to a number of problems. Another issue is that while PQC algorithms are designed to address the threat posed by quantum computers, they are not necessarily better or more secure in other respects. PQC algorithms are relatively new. Rainbow, for example, was one of three digital-signature finalists in the third round of the NIST PQC process, but was subsequently subject to a classical attack that allowed private-key recovery for its category-1 parameters in a little over two days on a single laptop. GeMSS, a third-round alternate signature candidate, similarly suffered an attack that dramatically reduced its security and led to its elimination from consideration. There was SIKE as well, with a pretty novel kind of classical attack. I therefore don’t think we should introduce a generic preference for PQC algorithms in this draft. We have a process in RFC9904 for introducing new and deprecating old algorithms. Warmly, Roy _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
