Problem:

s2n-tls generally follows server preference for the negotiation of algorithms.

However, this isn't strictly true in the case of TLS 1.3 key exchange

Consider a case where the server prefers

[ secp384r1, secp256r1]

And there are the following clients.

client A
    key_share: [secp256r1],
    supported_groups: [secp256r1, secp384r1]

client B
    key_share: [secp256r1]
    supported_groups: [secp256r1]

If the server wants to drop support for secp256r1 it needs to answer the question of

Do all of the clients I'm currently connecting to support secp384r1

s2n-tls's currently behavior makes it difficult to observe this, because both client A and client B will negotiate secp256r1.

Solution

s2n-tls should allow a mode of "very preferred groups". The negotiation flow would be roughly the following

if client support groups has any overlap with server very preferred groups:
    use HRR if necessary to get the group
else
    normal negotiation flow

I think we already largely support this mechanism, but it's used for PQ. The solution is to expand it to arbitrary groups.

Need By Date:

November 20th.

Resources

Test confirming existing behavior: https://github.com/jmayclin/s2n-tls/blob/2025-11-04-key-share-investigation/bindings/rust/standard/integration/src/group_negotiation.rs