Need support for multiple key share entries in ClientHello

[RokadeAditi]

As per RFC 8446 "Clients can offer as many KeyShareEntry values as the number of supported groups it is offering"​ in ClientHello during TLS1.3 handshake

But currently OpenSSL does not support multiple key share entries corresponding to all the groups from supported_group list.
It sends only first preferred group in key share.​ And if server does not support it then it requires retry.

eg. if I have below given 2 groups in supported_group
secp521r1 (0x0019)
x448 (0x001e)
then Key_Share extension should contain "KeyShareEntry" value for both the groups. But currently key_share is sent only for 1st group i.e. secp521r1 (0x0019)

We need this feature (multiple key share entries ) support in OpenSSL.

[BugOfBugs]

Does this mean that client, and server can use only 1 key, even if I make 3: RSA, DSA, ECDSA?

Will your change allow to use multiple keys of same type, different strengths? For example, RSA: SHA1, and SHA256. Client, and server would choose key to match maximum strength that they have.

My tutorial on configuration: #21643 (comment)

There I mention that manual states that can configure only 1 key of each type. Does not specify what type means.
Does that relate to this?

What retry do you mean? - By protocol TLS, or new connection?
Clients often do not try new. Because do not check cause of failure in library of OpenSSL. Or do not understand. Assume failure.
Or retry with same Group (Curve), and key. And fail again...
Retry should be a job for library OpenSSL, rather than application that calls it.

[mattcaswell]

Does this mean that client, and server can use only 1 key, even if I make 3: RSA, DSA, ECDSA?

Will your change allow to use multiple keys of same type, different strengths? For example, RSA: SHA1, and SHA256. Client, and server would choose key to match maximum strength that they have.

My tutorial on configuration: #21643 (comment)

There I mention that manual states that can configure only 1 key of each type. Does not specify what type means.
Does that relate to this?

This issue is a feature request that is only relevant to TLSv1.3. OpenSSL currently only supports one key_share in the ClientHello. The key_share uses a key exchange algorithm (e.g. X25519, X448, ECDHE with P-256 etc). Currently OpenSSL will use the first algorithm in the configured supported_groups list. See:

https://www.openssl.org/docs/man3.1/man3/SSL_CTX_set1_groups_list.html

By default, if no other configuration is applied, this will be X25519.

Your question is confusing the algorithm selected for key exchange in the initial key_share with the algorithm used in the server certificate. The former is selected by the client and is completely separate to the certificate types configured on the server side.

What retry do you mean? - By protocol TLS, or new connection?

The term retry here is specifical referring to a TLSv1.3 HelloRetryRequest message (HRR), i.e. part of the TLSv1.3 protocol.

[ajbozarth]

There seems to be discussion around this topic in #22203 and on behalf of @martinschmatz I would like to start work on this. Before starting I just wanted to confirm interest from the maintainers to not waste development time on a feature that has no path forward

[mattcaswell]

I think there is interest in having this feature.

[BugOfBugs]

Better count how many clients send multiple key_share, and how many times server retries for different key_share.
If none, may not bother. Less data is better for network.
May even remove groups (curves) other than X25519, as most clients present this 1st in list.

What happens on retry? Perhaps server lists its supported_groups to client. So, client can present 1 key_share again, and only 1 supported_groups chosen from list of server.

[martinschmatz]

@mattcaswell In analogy to the '?' prefix to ignore unknown groups in SSL_CTX_set1_groups_list, would it be acceptable to use a "!" as additional, optional prefix to indicate the desire to add a key share for this group?

Remarks:

1. For backward compatibility a key share for the first group in the list would always be added.
2. The implementation will have to make sure that the sequence of '?' and '!' prefixes don't matter for ease of use. Read: Valid prefixes would be '?', '!', '?!' and "!?'.

[t8m]

@mattcaswell In analogy to the '?' prefix to ignore unknown groups in SSL_CTX_set1_groups_list, would it be acceptable to use a "!" as additional, optional prefix to indicate the desire to add a key share for this group?

Yeah, that would work IMO.

[martinschmatz]

@t8m FYI - a first version to support multiple key shares is 'wiggling' (= basic operation with more testing required).

One question came up: Do we want to limit the number of key shares?

The standard does explicitly state: "Clients can offer as many KeyShareEntry values as the number of supported groups it is offering"

OTOH, if a user is 'blindly' sending key shares for all its (quantum-safe) groups, this will generate a lot of traffic on the server side. Therefore, I'd prefer a max of 4 key shares to be allowed.

This also has an impact on implementation (and performance): With limitation to max 4 key shares, an array can be used to keep track of key share variables, syscalls for dynamic memory allocations are required otherwise.

[t8m]

I have no problem limiting the number of key shares. Perhaps use this construction so the number can be overridden at build time.

#ifndef OPENSSL_CLIENT_MAX_KEY_SHARES
# define OPENSSL_CLIENT_MAX_KEY_SHARES 4
#endif