Post-Quantum Cryptography (PQC) Group Recommendations for TLS 1.3
Hello everyone,
This discussion is a follow-up to the conversation started in Issue #28069 and the related pull request #28076 regarding the need to update our recommended list of TLS 1.3 groups to include Post-Quantum Cryptography (PQC).
As pointed out in Issue #28069, our current guidance in SSL_CONF_cmd.pod is based purely on the performance of classical groups (x25519, secp256r1, etc.) and does not account for the emerging need for quantum resistance.
The subsequent discussion on PR #28076 highlighted the core challenge we face: there is no simple, objective metric to create a single ranked list that balances performance with risk mitigation. Deciding on a "performance/risk-mitigation mix" is a subjective exercise that requires community consensus.
The goal of this thread is to formalize this discussion and work towards a resolution. We need to decide how to best guide our users in this evolving landscape. Key questions to address include:
How should we structure our recommendation? Should we aim for a single list, or provide guidance based on different risk and performance profiles?
What would a sensible, forward-looking default group list look like for future versions of OpenSSL?
What is the clearest way to present this guidance to users in the documentation?
Michael BaentschTue 17 Feb 2026 6:13PM
I think the PR could be merged as-is and immediately: It has two approving reviews since more than a month. But I do not want to vouch any more as to its definite accuracy with the current code base, though, as I "tuned out" of that a bit, also due to this.
The Open Hours concept is a good thought -- but it requires willingness and time of both, people interested in landing PR and those facilitating that (aka review). And time is a precious resource. Getting it from two types of people in different geos at the same time is a serious challenge, I'd think.
To avoid things like this happening, why not simply track issues & PRs bringing those with a "long beard" to someones attention with the interest to move things? Doesn't need (to be) an engineer: I have a script for that --that doubtlessly can be immensely improved-- giving anyone with time to look suggestions what may be done/who may be "tickled" to "keep moving" any (incl. "community") issues (PRs also are GH issues :): See also here.
Jon Ericson ·Tue 17 Feb 2026 5:45PM
@nictuv and @baentsch That is unfortunate. For the PR itself, if someone were to review it would it be possible to merge or has it been completely overtaken by events?
For the bigger picture, I wonder if the open hours concept could be part of the solution?
I will check with the engineering folks too. This is clearly a deficiency in the process.