Perhaps you just want to be able to include e.g. early key shares for both X25519MLKEM768 and x25519 (and still have other groups in the list with no early key share)?

Yes this is what I actually want to do.

What "problems"? Early key share groups are an optimisation only; all algorithms can still be negotiated at the cost of an extra round-trip.

The problem here is we have prioritized some algorithms in the early key share group supporting logic [1]. If I set both X25519MLKEM768 and x25519 as supported key share groups, according to this logic [1], x25519 will be selected as the key share groups whichever the priority order is. In PQ TLS, we should priotizise PQ key share groups first and then the x25519 should be the the callback option. Otherwise since almost all the nodes support X25519 they won't go to PQ algoritms at all.

Feel free to propose a default behavioural logic for selecting early key shares.

This PR [2] was created on my proposal logic. Here the client can sent upto two namedgroups: one classical algorithm and one PQ algorithm.

• The classical algorithm is chosen in the same logic used currently [1], prioritizing x25519 and secp256r1 first.
• The PQ algorithm will be the first PQ algorithm from the list of namedGroups.

[1] https://github.com/bcgit/bc-java/blob/main/tls/src/main/java/org/bouncycastle/tls/AbstractTlsClient.java#L422
[2] #2052

TLS servers are not supposed to consider the early key shares when selecting a group; only the supported groups. After the group is selected, the server looks for whether an early key share is present. So the choice of early key shares should only be an optimization and doesn't affect the priority for selection of the supported groups.

(In case you are testing with a BCJSSE server, note that this described server group selection behaviour was only fixed for BCJSSE in the recently released 1.81 version).

I am testing with a BCJSSE client and I want to implement PQ TLS in the same way Chrome browser does TLS handshake. In Chrome both x25519 and X25519MLKEM768 are sent as early key shares. Can we do the same for BCJSSE as well?

@peterdettman I also have to use the same way "I am testing with a BCJSSE client and I want to implement PQ TLS in the same way Chrome browser does TLS handshake. In Chrome both x25519 and X25519MLKEM768 are sent as early key shares. Can we do the same for BCJSSE as well?"

• Any update on it when it is going to implement it that is sending multiple keys shares?
• Any reason why it is not implemented till now(as other libraries openssl supports it)
• Any other way out to do the same(one we know Using the low-level TLS API (e.g. subclassing AbstractTlsClient) one can override getEarlyKeyShareGroups for precise control )

In the current BCJSSE client implementation, if ECDH algorithms are present in the list of supported named groups, one of them is always used for early key shares, regardless of the presence of other algorithms. Since the BCJSSE server accepts only the single key pair received in the ClientHello, even when both the client and server use BCJSSE, the handshake occurs in classical TLS.

Even if we try to communicate between a BCTL client and a BCTLS server. It will use x25519 for handshake. So BCTLS client cannot use PQ TLS until this issue is solved.