On Tue, Oct 14, 2025 at 10:14 AM Petr Menšík <pemensik= [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. > I see that this draft was recently published, but hasn't seen discussion on list yet: https://datatracker.ietf.org/doc/html/draft-sheth-pqc-dnssec-strategy-00 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. > See this attempt a few years ago to propose algorithm negotiation in DNSSEC: https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-03 It was discussed at IETF at the time, but there was significant pushback (mainly no compelling justification to introduce such additional complexity). I still think it's a reasonable idea though. Shumon.
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
