Description
Problem:
This PR updated s2n to always upgrade to hybrid PQ when available, even if doing so required a 2-RTT handshake: #4526
The logic in this PR detects PQ by whether a hybrid algorithm or standalone algorithm is used. This logic has the assumption that all hybrid algorithms are a combination of PQ+ECDHE, and all standalone algorithms are ECDHE-only. s2n-tls does not yet support any standalone PQ key agreement algorithms so this assumption is currently correct, but will not be correct once MLKEM1024 (standalone) is added. MLKEM1024 support is required by CNSA 2.0, and will likely be the first standalone PQ key agreement algorithm added to s2n-tls.
Need By Date:
This work should be done before (or at the same time) that MLKEM1024 standalone support is added to s2n-tls. This will likely be done at the same time as #5152
Solution:
Update s2n_extensions_server_key_share_select() in s2n/tls/extensions/s2n_server_key_share.c to insert another PQ-standalone option between Option 2 and Option 3 here: https://github.com/alexw91/s2n/blob/04b22d727160c27cb51880092424decd735dc5d9/tls/extensions/s2n_server_key_share.c#L429
Requirements / Acceptance Criteria:
A client whose only supported PQ algorithm is MLKEM1024, and who offers the MLKEM1024 IANA identifier in their SupportedGroups extension, but does not include an MLKEM1024 KeyShare will always be upgraded to MLKEM1024 in a 2 round trip handshake, regardless of what other standalone ECDHE groups or key shares are offered by the client.