Post-Quantum Cryptography (PQC) Group Recommendations for TLS 1.3

Being from an exotic platform (MPP vs. SMP), even if the recommendations are grouped together in one area/page (a good idea), we should address, as best as we can, the differences. It is difficult in the best of situations to provide performance recommendations. For an unrelated example, in an MPP environment, Kernel Threads are ultimately slower than User Threads based on the cost of process context switching. I suspect that different internal chip architectures will not have consistent performance behaviour for any given algorithm. My suspicion is that we will need to document performance as we learn about it even if we try to be proactive. This is not a simple topic nor will it ever be, in my view.

My actual concern is not so much structuring the information but actually learning about it. How will we capture real performance data across the vast ecosystem with many chips and architectures?

It seems to me the discussion here and the issue/pr is overlapping different things, that probably ought to be answered separately.

My reading of Victor’s comments is that he believes we should remove the current documented list of recommended groups and instead insist that the users rely on the default group selection (which is supposed to be updated sensibly and regularly) and discourages any custom selection of groups unless the users really need it and know what they are doing.

What Michael suggests is to update the current documentation about group recommendations for our users, considering that anyway it already fell out of sync compared with our default group list. He is then asking GH contributors and community members here to define how to formalize the prioritization criteria to form our uptodate recommendation , before eventually applying those criteria to the default list.

To me it seems these 2 perspectives are coming from completely different angles and will have trouble meeting in the middle with a satisfactory compromise.

The selection process to update the current version of the default groups was based on an analysis of what other popular client and servers are doing in the PQ era and align our choices with that to minimize risks of HRR or of dropped connections, while keeping an eye on performance and security guarantees.

Is anyone objecting to the current list of default groups? Should we rather update the documentation not to recommend some alternative preference order for all the possibly supported groups, to instead document what our current defaults are and what were the criteria used to make such selection so they can be reapplied to update the default selection and the documentation as time passes by?

For the record: Red Hat / Fedora /CentOS, and, I presume, their clones provide system-wide settings, including kex groups, that change from time to time, and we expect that users normally would not override these settings

My view is that the situation when the default group list differs from the recommended group list would be very strange, inconsistent and disorienting. That's why I disagree with the idea of changing the recommended group list in any way. Moreover, I'd suggest not providing the recommended group list in the documentation, but instead describing the default list, preferably with an explanation of why it is the way it is.
On the other hand, I agree with @Michael Baentsch that while there are only classical groups in the list, it is necessary to provide users with some recommendations about PQ groups. Something like "If you are concerned about post-quantum threats, we recommend..." Maybe some other special cases when it is worth using non-default groups should also be mentioned.

The selection process to update the current version of the default groups was based on an analysis of what other popular client and servers are doing in the PQ era and align our choices with that to minimize risks of HRR or of dropped connections, while keeping an eye on performance and security guarantees.

Thanks very much @Nicola Tuveri -- this is the first time I'm seeing a written rationale for the current group defaults documented in this clarity -- though also without a clear and objective spec as to how (and where) "performance" and "security" are (measured), which is the same --correct-- criticism leveled against https://github.com/openssl/openssl/pull/28076.

What about this proposal then: The PR gets changed to

• refer to the current default groups

• stating that this selection is based on "current" (add date?) choices of what other TLS software does (would be nice to state which packages serve as reference) in order to minimize HRRs

• that this considers the threat of Q-computing somewhat by adding a "common" (see above: list reference/d TLS stacks) hybrid in

• that this default selection therefore is subject to change (as other SW packages may change, performance may change, the risk perceptions regarding Q-computing may change)

OK for everyone?

Still open questions in my mind:

• Would it still be worth while adding that there are further alternatives (slower algs, pure PQC algs, etc.)? I'd still think that people should be given pros and cons of alternatives and not just be told "believe us, we know best".

• Would it be possible to point to a documented mechanism by which the default gets reviewed, e.g., at every release or by community input (provided by which means) or... ? This surely must already be documented somewhere given the large number of such defaults. I'm just now aware where this is documented (and/or whether it may be worth while re-documenting in the presence of TACs/BACs).

We discussed this in today's OpenSSL Foundation TAC meeting and the TAC reached consensus on:

• Replace current documentation recommendations with the actual 'default groups list'

• Change "recommended groups (in order of decreasing performance)" to "default groups"

• Drop subjective performance rankings entirely

• Document that defaults already include X25519MLKEM768 (hybrid PQC) as primary keyshare(adding X25519MLKEM768 at the top of the default list)

• Additionally, can also briefly document other options for specific use cases (high-quantum security environments needing more hybrid/pure PQC algorithms, legacy systems requiring classical-only configurations)

Rationale: The TAC agreed that most users would simply use OpenSSL's defaults rather than override them. Since the current defaults already provide post-quantum protection via X25519MLKEM768, the documentation just needs to reflect this in the list.

Thanks for the decision. PR updated accordingly. Will create separate discussions for the unresolved questions above. Please let me know if this would not be welcome.