Hi Libor, On 29 Jun 2026, at 12:06, Libor Peltan <[email protected]> wrote:
There is a trick available which might or might not be a good idea: Define a single DNSSEC "algorithm" (with a given assinged number) which in fact uses different cryptographic algorithms for KSK and ZSK, respectively. It would be completely okay for RFC 4035 and all the DNSSEC operations, since from the perspective of DNSSEC it's still a single "algorithm"; and it would do the proposed job of quantum-secured DNSKEY signature and small other signatures. Brr. That’s creative, I agree. But I hope we’re not quite that desperate for a PQ-DNSSEC solution (yet). Let’s first try to find a clean solution. Regarding relaxing RFC 4035 requirements: I think it's pretty difficult. Not denying that. But that’s not where I think we should start. My view is that we have a hard problem to solve and then we should try to find the best solution. Once we have a solution we’ll obviously have to pay a price somewhere. And no matter what, validators will have to be updated, and that is obviously an opportunity. For now, I'd like to see draft-huque-dnsop-multi-alg-rules move forward. Yet your question seem to be slightly different. Yes, they are somewhat overlapping, but have different focus. Shumon’s focus, AFAIK, is multi-signer with disjoint algorithms among providers (which is obviously also interesting to me). My focus is making PQ-DNSSEC viable by limiting the size expansion to only hit the DNSKEY RRset (and then not query for DNSKEY over UDP). I’ll upload a new version of the dnssec-alg-split draft shortly. The new version will expand on the very much simplified mechanisms for algorithm rollover that follows with different algorithms for KSK and ZSK. Suddenly algorithm rollover almost becomes easy (obviously assuming the validator supports both old and new algorithms, but that’s always a prerequisite). Johan
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
