Change logic of choosing early key shares

[linukaratnayake]

In the current implementation, if either the x25519 or secp256r1 algorithms are present in the list of named groups, one of them is used for early key shares—regardless of the presence of other algorithms. However, with the growing adoption of post-quantum cryptography, it is increasingly important to include post-quantum secure algorithms (i.e., KEM-based algorithms) in the early key shares.

Section 4.2.8 in the RFC 8446 mentions the following:

Clients can offer as many KeyShareEntry values as the number of supported groups it is offering, each representing a single set of key exchange parameters.

This means it is valid for clients to include multiple KeyShareEntry values corresponding to different named groups.

Updated Logic

The updated implementation modifies the selection logic for early key shares as follows:

• If no KEM-type algorithms are present in the list of named groups:

  • If x25519 or secp256r1 is present, it is selected (in that order of preference).
  • Otherwise, the first algorithm in the list is used.

• If one or more KEM-type algorithms are present:

  • The first KEM-type algorithm from the list is selected.
  • Additionally, the non-KEM algorithm is chosen using the logic above (can be omitted if none qualify).
  • Both selected algorithms are included in the early key share groups, preserving the order in which they appear in list of named groups.

This change ensures early key share negotiation includes support for post-quantum algorithms while maintaining backward compatibility with existing logic.