There has also been some research in the area - mine and UTwente on the usable algorithms.
We already have algorithm flexibility in DNSSEC (one validating path is enough), so I am not really sure what is the problem that you are trying to solve. Ondrej -- Ondřej Surý (He/Him) [email protected] > On 14. 10. 2025, at 17:13, Petr Menšík <[email protected]> > wrote: > > Hello! > > I have been thinking whether there is a good plan how to switch to > post-quantum resistant algorithms in DNSSEC. I am a software engineer at Red > Hat and there are a lot of more qualified people about the cryptographic part. > > But it seems to me one thing is obvious. New signatures of whatever > algorithms would be somehow large, compared to what is used today. I think > the only working model for early adoption is to not punish new zones signing > in less common algorithms is to dual sign with some proven and common at the > same time. OpenSSL has nice support for such thing on TLS channels. But dual > signing in DNSSEC has mostly disadvantages and is avoided for a good reason. > > I think we need some way how to make it easier to offer less common > algorithms. I have been thinking about how to do that and put together > document with my idea. It is not a draft quality, I have never written RFC > draft for even trivial EDNS extension. But I failed to find something similar. > > I think it would need to support new algorithms and old algorithms together > for some time. Just like it is expected on TLS channels. > > My idea is to have something similar to RFC 6975 DAU record, but a modified > variant with primary and backup algorithm sets. Authoritative servers would > then send only signatures types requested. I expect authoritative zones would > be dual signed. But validating clients could fetch only signatures they want. > Or their clients want. > > More at my gitlab [1]. I have explained it on DNS-OARC DNSdev room. One of > results were this it way too complicated to pass on DNSOP. > > I think such support might help also standardized algorithms 15 a 16 to > become more used. They have minimal usage today. > > Is there any other plan, how to gradually deploy newer DNSSEC algorithms, > even experimental ones? Without trying them only on zones appearing insecure > to majority of older validators? Or waiting ages before they are supported > almost by everyone? > > Answer here, at DNSdev room or create issues at my gitlab. Is my idea worth > trying it as a normal draft? Does it make sense to you? > > Thank you in advance. > > Best Regards, > Petr > > 1. > https://gitlab.com/pemensik/dns-rfc-proposals/-/blob/main/dnssec-dual-signing.md?ref_type=heads > > -- > Petr Menšík > Senior Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > _______________________________________________ > 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]
