Support for multiple key share entries in ClientHello

[hwupathum]

Are there any plans on supporting multiple key share entries in ClientHello for TLS 1.3 as OpenSSL has implemented [1]?

We can either use all the key share entries defined in the client or use some logic to select / prioritize which key share algorithms to be sent.

[1] openssl/openssl#21633
[2] #2052

[peterdettman]

Using the low-level TLS API (e.g. subclassing AbstractTlsClient) one can override getEarlyKeyShareGroups for precise control (including multiple shares of course).

Using BCJSSE, there's (to my knowledge) no JSSE API that can control this selection. Apart from fiddling around with the default selection logic, we would need to add BCJSSE extensions to help here.

A first (simple) option is to add a BCSSLParameters method to simply set the list of groups to send shares for.

A second (more complicated) option is a session-like mechanism that tracks what group was previously negotiated for a server (and/or supported_groups sent by the server). For repeated connections/sessions on a given server this adaptive selection should mostly predict "ideally".

[hwupathum]

jdk.tls.namedGroups property can be used to change the named-groups used by the BCTLS clients, but only the first namedGroup of the client is used to send key shares.

This causes problems specially with PQ TLS algorithms. Specially if the client is suporting a PQ TLS namedGroup, it should also support traditional nameGroups as well (in case the server does not support PQ algorithms). That is how the OQS implementation is done as well

[peterdettman]

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

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)? Feel free to propose a default behavioural logic for selecting early key shares.

The problem of course is that everyone has to use that same logic, because JSSE doesn't provide an API to customize it, which is why my reply above focuses on how to allow that customization.

[hwupathum]

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

[peterdettman]

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).

[hwupathum]

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?