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

@Michael Baentsch feel free to provide more description or your thoughts if needed.

No. I already provided my thoughts in Github and will keep doing so. I further think it's sensible for all discussions to happen/arguments to be exchanged in one place where everyone with an interest to provide their views is able to see it and give feedback. For me, this place is Github and not some separate discussion forum with an unknown set of participants. This discussion item here is good to make "non-coding" people aware that a decision is required and this tool may be used to drive a vote if necessary, but arguments one way or another in my opinion should "stick with the code": Irrespective of how the discussion goes, it will be implemented in code and GH provides the mechanism for "posterity" to see why the code is how it turned out to be.

@Michael Baentsch The difficulty is that there’s no single objective way to balance performance with quantum-resilience, so any recommendation inevitably involves judgment about trade-offs. That makes this both a technical matter and a governance matter.

You are absolutely right that GitHub is the canonical place for technical arguments and implementation details. That’s where the rationale will remain tied to the code for posterity, and it’s the right forum for developers and cryptographers to hash out benchmarks, trade-offs, and the final decision.

At the same time, this decision also affects how we guide our wider user base — businesses, distributions, and other stakeholders who may not follow GitHub threads directly. openssl-communities.org is not meant to fragment technical debate, but to raise awareness that a decision is pending, provide a channel for non-coding participants to express their views, and capture the governance record of how the wider ecosystem was engaged.

Both are needed to get this right.

raise awareness that a decision is pending

This I fully agree with -- already in the statement above.

provide a channel for non-coding participants to express their views

alright -- but this then demands a link back from the GH discussion to the non-technical discussion venue. So my "generalized request" then is that anyone who triggers a discussion here based on a GH issue each time places two links: One from GH here and one from here to GH. OK to add this to the "process" (and document it)?

capture the governance record of how the wider ecosystem was engaged

also good -- together with the above-requested "always link back" requirement this seems to demand that these discussions are as permanent as GH discussions. Is this guaranteed (particularly, if the discussion gets moved around to different community locations)? If not, worthwhile adding as a feature?

@Michael Baentsch Agreed. Cross-linking both ways makes sense and we can adopt it as good practice, and openssl-communities.org is intended to provide a lasting record, not something ephemeral. It will take some time to formalize all this, but your points are well taken.

My point of view is simple: we should prioritise all of the PQ hybrid algorithms at the beginning of the list. After this, I'm less concerned about the ordering and the mix between PQ and classical algorithms. Although with a slight lean to PQ before classical. Within these categories, most performant first is reasonable.

Why?

There are store now decrypt later attacks underway now (and have been for decades). The faster we move to something that's safe by default against these attacks, the better. This means a PQ algorithm or a hybrid. Since the PQ algorithms are fairly new, hybrids seem like the prudent choice.

Any classical only key exchange is vulnerable, so we'll be in a spot of bother if a PQ algorithm is broken and cryptographically relevant quantum computers are viable. But that's something beyond our control.

Our current default group list is: `?*X25519MLKEM768 / ?*X25519:?secp256r1 / ?X448:?secp384r1:?secp521r1 / ?ffdhe2048:?ffdhe3072`

We do not have `SecP256r1MLKEM768` nor the pure PQ algorithms there, maybe they should be added? However the pure MLKEM algorithms are not really deployed anywhere currently. What we definitely do not want is to put slower groups than ffdhe3072 in the list.

#28069 lists four non-hybrid algorithms between SecP256r1MLKEM768 and X448MLKEM1024. Then x448 before SecP384r1MLKEM1024. I don't see why there should be any non-hybrid algorithms list before all of the hybrid ones have been lists. I.e. favouring performance over security seems like an odd trade off. Even being perceived as doing this wouldn't be good for the project's image.

The reality is that most PQ ready installations will pick X25519/MLKEM768 since it's first and good enough.

I don't see why there should be any non-hybrid algorithms list before all of the hybrid ones have been lists. I.e. favouring performance over security seems like an odd trade off

This absolutely has not been my intention. I simply "carried forward" in the PR the previous logic (that did favour performance -- without immediately obviously taking risk/security, e.g., bit lengths, into consideration).

Thus, if we agree that hybrid algorithms always are more secure than non-hybrid ones (do we?) then the proposed order becomes more clear:

• hybrid > pure quantum > pure classic; each set ordered by performance

Our current default group list

Again, as stated in https://github.com/openssl/openssl/issues/28069 the issue is not about changing any currently deployed defaults but to document what OpenSSL recommends going forward (but obviously not violating that recommendation within the coded defaults) such as for users to change things as they develop their use cases. My thinking was that default groups then may later follow suit (adding more groups) as and when "real world deployments"/use cases make this seem sensible.