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]

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?

[garishmanagpal]

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

[hwupathum]

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.

[peterdettman]

I've added BC-specific mechanisms to support configuring the early key_share groups that a BCJSSE client will send.

There are two supported mechanisms:

1. A system property "org.bouncycastle.jsse.client.earlyNamedGroups" with the same syntax as jdk.tls.namedGroups i.e. a comma-separated list of group names. Groups must be separately enabled (e.g. by default or via jdk.tls.namedGroups or SSLParameters.namedGroups) or they will be ignored. This property is read whenever a BCJSSE SSLContext is created and will affect all client connections using that SSLContext.

2. A BCSSLParameters.earlyNamedGroups property, which is a list of group names like SSLParameters.namedGroups. SSLSockets created by BCJSSE can be cast to BCSSLSocket (resp. SSLEngine/BCSSLEngine) so that setParameters can be called with a BCSSLParameters instance. This mechanism allows per-connection configuration and will override any system property settings.

In both cases, a completely empty list will cause no early key shares to be sent, while not setting either will result in the existing default selection behaviour.

[peterdettman]

FYI, things were renamed to "earlyKeyShares" i.e. "org.bouncycastle.jsse.client.earlyKeyShares" system property and BCSSLParameters.earlyKeyShares property.