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.

@Michael Baentsch @Aditya Koranga - were changes discussed and agreed by TAC got merged in the end?

As is visible in GH, unfortunately, No: I changed the PR as per decision above in my commit immediately (still on Sep 22) expecting equally immediate approval at least then, but separate changes got added as further review comments on Dec 28 (that I found misplaced in the PR).

I have to admit that in (possibly, due to) this long and winding process (stretching since PR creation on Jul 23) I lost interest in pushing things further: Having to wait weeks and months for PR approvals and then going through a discussion here, still without getting approval to landing some imo trivial non-code contribution made me think that this isn't worth my effort (or it's simply not welcome)... mea culpa.

This is a very unfortunate outcome.

@Jon Ericson @Hana Andersen it seems we need to recommend the engineering management to ensure processes are in place to avoid community contributions to fall into oblivion in case some of the engineers/reviewers effectively puts it on hold.

I have the impression this is not a problem for contributions that end up tracked in the `openssl/project` repository, but I am not sure there is a path for community contributions to consistently get there so that they are handled across springs or accounted for in the backlog metrics.

@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.

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.