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

[martinschmatz]

Code is running, survived first tests. Here a first write-up of what the code change will do, to be added here:

If a group name in SSL_CTX_set1_groups_list() is preceded with 
the ! character, the way key shares are generated on the client 
side and how groups are selected on the server side is influenced
during a TLS v1.3 handshake process:

On the client side, a ! prefix for a group in the list of groups will add 
a key share for this group. By default, a maximum of 4 key shares is 
supported, which can be influenced during build time by defining 
OPENSSL_CLIENT_MAX_KEY_SHARES with a different value.

On the server side, the list of supported_groups and key_shares 
as received in the ClientHello is used in combination with the list of 
server-side groups - including any potential ! prefix in the sense 
of 'requested key share' - to select which group the server chooses. 
Four possibilities exist as shown in the table below, with sequence 
is priority (=> how to read the table: If entries in the client side 
list have overlap with the server side list, do the overlap action; 
if not, use the next line and repeat): 

   Client                  Server                    If they overlap
1) keyshare list           requested keyshare list   SH with the leftmost group_id from server requested keyshare list
2) supported groups list   requested keyshare list   HRR with leftmost group_id from server requested keyshare list
3) keyshare list           supported groups list     SH with the leftmost group_id from server groups list
4) supported groups list   supported groups list     HRR with leftmost group_id from server groups list
[HRR = HelloRetryRequest, SH=ServerHello]

If no ! prefix is present anywhere in the entire list of groups on the 
client-side, a single keyshare is sent for the first group in the client-side 
list of groups. 

If no ! prefix is present anywhere in the entire list of groups on the 
server-side, the server will select the first key share group present 
in the ClientHello which it also supports.
If no such key share is present, it will then select the fist group in the list
of supported_groups as received in the ClientHello which it also supports.

When using the built-in list of groups, no ! prefix is specified.

[BugOfBugs]

Limit on quantity of key_share violates RFC, and purpose of this issue to remove limit.
You would rename the issue: limit to 4 rather than 1.

Limit on client is appropriate, as it is supposed to choose. However, choice should be by user, rather than hard code in software (fixed). Better allow choice in configuration.
Do you apply limit only to client? If also to server, what would it do? - Ignore what client presents in excess? Then more traffic ensues. Not less.
Limit should rather be quantity of prefix "!". No need for additional, fixed limit. It may even confuse user.

You can reduce traffic by different means. I suggested to log clients, and servers in order to limit supported_groups, and key_share to what they usually have.

with sequence is priority

Makes no sense. Change words.

requested keyshare list
SH with the leftmost group_id from server requested keyshare list
HRR with leftmost group_id from server requested keyshare list
server will select the first key share group present in the ClientHello

#22203 sates that it is a bug to treat key_share as preference. - Both for client, and server. Instead, must choose 1st supported_groups of client. HRR, if its key_share is absent.
There would be less code. 2 "actions" instead of 4 per your list. Less traffic.
Hence, prefix "!" on server is redundant.

When using the built-in list of groups, no ! prefix is specified.

Rephrase: If you do not add supported_groups, then OpenSSL uses built-in groups. This implies absent prefix "!".

[martinschmatz]

Limitation to 4 key_shares is intended and it's well understood that this choice deviates from the standard - unless one takes "In the absence of an application profile standard specifying otherwise [...]" into consideration.
Implemented limitation on the quantity of '!' prefixes is only on client side, server is [technically] free to use it for none/any/all supported groups. The client has a free choice which of its supported groups he wants to prefix with a '!' (up to 4 x '!'), both in the config file as well as on CLI of applications like cURL.

The standard is clear that the server is free to use whatever algorithm it wants to make a choice for a group: "The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection." and "If the client has not provided a sufficient 'key_share' extension (e.g., it includes only DHE or ECDHE groups unacceptable to or unsupported by the server), the server corrects the mismatch with a HelloRetryRequest [...]".

Can't work with statistics in my environment.

Thanks for your considerations about wording, will be taken into account once documentation is finalized.

[BugOfBugs]

understood that this choice deviates from the standard

You merely confirm that you violate standard.
But that is what I argue against.

free choice... up to 4

You take away freedom. Yet call it freedom.
You do not need limit. You merely invented it.
Leave it up to user. Quantity of "!" is already limit. User is free to change.

server is free

You mean there is no limit 4?
You discriminate only client.

Can't work with statistics in my

Can you examine logs?

My word statistics was inappropriate. It means non-specific. I meant specific, memory about each client. I edited my post to change the word to log.

You would see that most clients submit only 1 key_share, for 1st supported_groups.

[martinschmatz]

@BugOfBugs It was understood already in your post further up that you argue against limiting the number of key_shares sent by the client.
The arguments I 'invented' in favor of limiting are also found above.

Confirmed: Server is [technically] free to use a '!' prefix for none/any/all supported groups.

And yes, I had the opportunity to look at some logs in the past - but still can't use what you suggest in my environment.

[BugOfBugs]

@martinschmatz

It was understood

My purpose was not to repeat myself.
Rather to inform that yours is not reply.
Reply is due.

arguments found above

There are no multiple arguments. Only 1: avoid syscalls for dynamic allocation of memory.
It would be consideration, if allocate dynamically, many times, per connection.
Actually, it would happen only statically, 1 time, per configuration.
I suggest dynamic quantity of key_share. Even then can allocate but once, with maximum margin.

You did not argue against using quantity of prefix "!" as maximum key_share.

Confirmed: Server is [technically] free to use a '!' prefix for none/any/all supported groups.

You ignore my point that it is a bug to treat key_share as preference.
Order of supported_groups is the only preference. It matters only on client. server chooses that, unless configured to prefer its own.
Prefix "!" on server is redundant. It is extra preference on supported_groups that is in order of preference already.
Add it only to client. Not as preference. Rather as prediction what server chooses.

Correct 2 steps should be:

1. Choose 1st supported_groups of client that server has. Regardless of preference on server.
   Or vice-versa, if configured to prefer server.
   If key_share matches selection, then SH.
2. Otherwise HRR.

logs can't use

Your personal situation is not what OpenSSL should stick to.
It should log key_share. Users of client, and server would examine, and configure accordingly: single, or multiple key_share.

Additional feature could be to keep log in memory. Dynamically decide whether to use multiple key_share, and how many. Decide per connection, server, client, time of day, etc.

[martinschmatz]

@BugOfBugs

You seem to have missed the argument that default (build time configurable) limitation to a maximum of 4 Key Share Entries in the key_share extension of a ClientHello is mainly driven by the desire to limit network traffic arriving on server-side, specifically when using sizable Q-safe groups in the key_share extension. Avoiding dynamic memory allocation is a distant second priority.

When using a '!' prefix on client-side, quantity of '!' prefixes is equal to number of key shares. Always was, always will be - by way of how the '!' prefix is defined.

I didn't ignore your assessment that "treating key_share as preference is a bug". I simply referred you to previous post further up where I already explained what the standard prescribes: "The standard is clear that the server is free to use whatever algorithm it wants to make a choice for a group".
As a consequence, a '!' prefix on server side is most certainly not redundant as it introduces (a) true server preference, in addition to existing client preference when no '!' is used, and (b) a second level of priority for server-side group selection - which is a highly desirable (read: must have) feature in the context of migration to Q-safe TLS. I suggest to (re-)read the proposed documentation further above.

The fact that I can't use logs in my context does not imply that it would not be possible to create such logs using OpenSSL (hint: SSL_set_msg_callback(...) available since v1.0.2). As such, no extra work is required to create logs - which any user can leverage to create adaptive behavior as deemed required.

This post only in case it helps somebody to understand what we try to achieve. Based on your various posts I concluded for myself that you have no clue what you're talking about and that you are either unable or unwilling to read posts thoroughly, which implies that I added you to my personal troll filter. Bye.

[BugOfBugs]

missed argument

I did not. We presume a benefit minimal communication.

Avoiding dynamic memory allocation is distant priority

Do you agree to drop this excuse?

quantity of '!' prefixes Always was, always will be - by way of how the '!' prefix is defined

You yourself suggested the opposite: "!" is your invention, new.

I didn't ignore your assessment that "treating key_share as preference is a bug".

Your algorithm suggests that you do ignore. Steps 1, and 3 choose by key_share.
Instead, use my algorithm.

server is free to use whatever algorithm it wants to make a choice for a group

This is no justification to break documentation. That says preference is supported_groups.
You create bug (perpetuate existing one) that other issue will remove. They will discard your new code, and implement my algorithm.
I suggest you wait till they remove this bug. Afterwards reintroduce it. So that their work is lost, rather than yours.

As consequence

Not consequence.

'!' prefix on server side is not redundant

I proved it is.

introduces true server preference

supported_groups is preference.
No need for one more: "true".

second level of priority for server-side group selection - which is a highly desirable (read: must have) feature in the context of migration to Q-safe TLS

You never mentioned this. New argument.
- Wrong. "!" is not specific to Quantum-computer-safe.

I suggest to (re-)read the proposed documentation further above

I failed to find the mention. Please link.

possible to create such logs SSL_set_msg_callback(...)

Is not log, such.
Only stop for application to allow inspection.

no extra work is required to create logs

- Wrong. Application still needs to decide which data to inspect. Still needs to log on its own.
I suggested that OpenSSL logs, and keeps it in memory in order to optimize quantity of key_share.

I assume that your answer means that you retract your argument that you can not use logs.

you have no clue

Please delete this paragraph as nonsense.

added you to my troll

My pleasure.
You are not fit to create code.
Is there anyone to revoke this right for @martinschmatz? Or is it free for all?

One such destructive person already left. I refuse to believe as if voluntarily he became ghost. I believe that supervisors of OpenSSL are vigilant, and good.
With every removal of bad participant ghost grows in popularity. It assumes all one's creation, followers, evil, and good.
There is no mark why he left. So, we are not sure whether indeed for his bad deeds.

[t8m]

@BugOfBugs @martinschmatz Please stop the unproductive and unprofessional ad hominem attacks immediately.

[vdukhovni]

Client Server If they overlap

1. keyshare list requested keyshare list SH with the leftmost group_id from server requested keyshare list
2. supported groups list requested keyshare list HRR with leftmost group_id from server requested keyshare list
3. keyshare list supported groups list SH with the leftmost group_id from server groups list
4. supported groups list supported groups list HRR with leftmost group_id from server groups list

The proposed server-side behaviour looks rather over-engineered to me. Forcing a client that presented a supported key share to HRR makes little sense to me, and requires some non-trivial justification. Otherwise, with "2" removed, the need for '!' on the server side goes away, just list the preferred (formerly required) groups first, and then "!" is only needed on the client side.

In terms of UX, placing "!"s in the list introduces complexity that is easily avoided, by just allowing the client to separately specify a count of keyshares to send, with that many groups implicitly "banged" as it were.

If there is a compelling reason for the server to force an avoidable HRR to force the client to send a different supported group, a similar count could be available server side, but I'm sceptical that this would be a good idea.

[martinschmatz]

CNSA 2.0 mandates to support and prefer Q-safe algorithms if available.

Therefore, when a client supports a Q-safe algorithm for the key agreement, the server must be able select it - even at the cost of a HRR (which btw probably hurts the server more than the client due to network load at an aggregation point).

Currently, server selects key-shares as per client preference. Hence, even if the client sends a legacy and a Q-safe key share (in that order), the server has no means to prefer the Q-safe key share group but will select the legacy key share group. One way to deal with that (without code change in apps) would be to extend the means available for server-side cipher preference (SSL_OP_CIPHER_SERVER_PREFERENCE) to simultaneously change the key shares selection algorithm to server preference. With code change in apps, a new option could be added to enforce server preference.

"allowing the client to separately specify" --> If I understand your proposal correctly, this implies code changes in apps using OpenSSL - which we try to avoid for many reasons. A prefix character for a group in the string specifying the supported groups OTOH is only implying a change in config file(s), hence crypto-agile and seamlessly & immediately available for any application leveraging OpenSSL (e.g cURL, HAproxy, Nginx, Python, PostgreSQL etc).

PS: The character used as prefix is certainly up for debate. '!' might not be the best choice, was used to show the principle.

[vdukhovni]

Well prefer is a flexible term, it doesn't specify how hard one should try to prefer, and certainly does not imply that one can't also prefer to avoid HRR.

As for a separate knob for the share count, it need not require any change in client software, if said client software already supports loading of configuration files (needed anyway to load providers for pq algorithms, and specify various other knobs).

Applications could of course implement direct support for the share count control, but delegating parsing of opaque config options to OpenSSL (from a file) or via the conf command API addresses this and future extensibility needs.

That said, yes, there needs to be a way for the server's group order to be primary when the client presents multiple key shares.

[martinschmatz]

@vdukhovni Point well taken related to 'how stringent is the prefer mandate'. I'll have somebody reach out to the CNSA2.0 owners (NSA) for clarification.

Fundamentally, I can identify the following scenarios (not implying that all are required, intended to structure the discussion).

Client: Need a way to specify multiple client key shares to be included in ClientHello.

Server (all below assume that there is some overlap in client & server supported_groups):

• Strong client preference: Server (1) selects first overlapping client key share group, then (2) first overlap from client supported_groups.
• Weak client|server preference: Server (1) selects first overlapping client key share group, then (2) first overlap from server supported_groups; OR server (1) selects its first group which overlaps with a client key share group, then (2) first overlap from client supported_groups.
• 1-layer server preference: Server (1) selects its first group which overlaps with a client key share group, then (2) selects its first group which overlaps with client supported_groups.
• 2-layer server preference: Server (1) selects its first high-priority (aka prefixed) group which overlaps with a client key share group, then (2) selects its first high-priority group which overlaps with client supported_groups, then (3) selects its first group which overlaps with a client key share group, then (4) selects its first group which overlaps with client supported_groups.

With the exception of the second server scenario (which value is anyway questionable at best), all scenarios can be addressed by the introduction of a prefix option in the respective lists of supported_groups, readily usable by any application which has a means to specify such a list,

• be it via code with or without related environment variable or command line option (e.g cURL, s_server, s_client, node.js, soon: Python,...),
• be it from their own config file (e.g. Nginx, HAproxy, httpd,...),
• be it from the OpenSSL config file.

[ghen2]

2-layer server preference: Server (1) selects its first high-priority (aka prefixed) group which overlaps with a client key share group, then (2) selects its first high-priority group which overlaps with client supported_groups, then (3) selects its first group which overlaps with a client key share group, then (4) selects its first group which overlaps with client supported_groups.

How will that work for applications that act as both TLS server and client?

Typically a client will want to send key_share for 1 PQC and 1 traditional group.
But a server will want to prioritize all PQC groups over all traditional ones?

[martinschmatz]

@ghen2 Client and server sides each use a colon separated string of optionally prefixed groups.

I guess you are well aware, but mentioning it nevertheless: TLS applications that are using OpenSSL are configured in two steps: First the config of a context is done, which can then be refined by configuring the SSL object.
Context config is typically preconfigured using the entries from the openssl.cnf file, and then (optionally) refined by settings defined in the application config file, and the actuall SSL connection is 'inheriting' these settings.
In the present case, it would be sufficient that client (/server) is initialized via openssl.cnf and the server (/client) is refining the input from openssl.cnf via its own config file.

You didn't mention an example for such an application (do you have a specific one?), hence I'm speculating: Such applications are typically either proxies or u-services. In both scenarios, at least the upstream server is (hopefully) not hard coded but defined in a config file or ENV variable. Which implies that the groups used for upstream also can be defined this way.
In HAproxy for example, one can add the group list for incoming connections ('server mode') in the bind line using curves key-word, and for outgoing connections ('client mode') in the server line again using the curves key-word. One can also rely on the settings in the openssl.cnf file for the bind line (read: not specifying any curves there) and the haproxy.conf file for the server line.

[martinschmatz]

@vdukhovni The clarification question sent to NSA was as follows:

[...]The client and server supported_groups overlap and both include matching Q-safe algorithms from the CNSA2.0 list, BUT also include matching legacy algorithms, AND the group of the ‘client key_share’ is legacy and is matching the ‘server supportd_groups’ BUT is NOT from the CNSA 2.0 list.
Scenario 1: The server forces a HRR (HelloRetryRequest) and thereby asks the client to send a key-share for the CNSA2.0 algorithm.
Scenario 2: The server accepts the group from the legacy ‘client key_share’ and sends an SH (ServerHello) with its legacy keyshare.

The response was (emphasis added by me):
[...]something along the lines of scenario 1 is the aim. As a general principal, if you can interoperate at the higher security level, you should try to do it whenever possible. Obviously I can imagine there could be places where scenario 2 is the only one that works due to latency or other issues, but this would generally not be in line with our goal. With the publication of the standards, there is a little more guidance coming soon on updated dates (and with less use of the word “preferred”).

==> We better prepare for a stringent interpretation of the mandate 'prefer' Q-safe key agreements.

[vdukhovni]

I see, so the ask is for servers to be able to implement:

all groups are equal, but some groups are more equal than others

based on plausible upcoming CNSA 2.0 requirements. And for clients I guess to be able to send more than one key share, because avoiding HRR by sending both a PQ keyshare and a "traditional" keyshare makes sense when many servers will support only traditional, while some will insist on (strongly prefer) PQ.

At which point we it remains to bikeshed the configuration syntax.

- The client needs to be able to specify how many of the keyshares it supports should be sent.
- The server needs to be able to specify which supported keyshares are more equal than others, forcing an HRR if supported, but not sent by the client.

In either case:

- Either by count of elements in preference ordered (highest first) list, or,
- By prefix character, such as `!`

Finally, if a client supports multiple unsent keyshare types "preferred" by the server, which should the server select for HRR? This would be either based on server, or client preference, and presumably should follow the extant TLS-1.2 server vs. client cipher preference control.

Is this a fair summary?

[martinschmatz]

@vdukhovni Yes, I'd say that's a fair summary.

I have to admit that I never thought about your last paragraph: Server or client preference when selecting the group in the HRR. Seems I work to often with servers...

Anyway, I think that could be addressed by using a '-' prefix on the client side for selection of key shares to be sent, and on server side to indicate client preference when selecting the group for the HRR, and a '_' prefix on server side to indicate server preference when selecting the group for the HRR. This again motivated by avoiding code changes.

Having said that, adding a new option SSL_OP_GROUP_SERVER_PREFERENCE in analogy to SSL_OP_CIPHER_SERVER_PREFERENCE might be a valuable addition in any case for situations where no prefix is used on server side.

[t8m]

SSL_OP_CIPHER_SERVER_PREFERENCE already applies to group selection if there is no matching keyshare. Doesn't it?

[martinschmatz]

@t8m Don't see any evidence for that, neither in the overview, nor in the relevant code section.

[t8m]

@martinschmatz what about https://github.com/openssl/openssl/blob/master/ssl/t1_lib.c#L947-L958

[t8m]

Hmm... but that applies to TLS <= 1.2 versions only apparently.

[ghen2]

You didn't mention an example for such an application (do you have a specific one?), hence I'm speculating: Such applications are typically either proxies or u-services.

Postfix would be an example of a client+server that talks to arbitrary endpoints in both directions.
nginx or haproxy will typically talk to a limited/controlled set of endpoints on (at least) one side.

But for either example I'm aware of only a single setting to control supported groups for both directions at once, not separately.

Example group list: (1) X25519+MLKEM768, (2) P-256+MLKEM768, (3) X25519, (4) P-256
As a client you will want to send key_share for 1 and 3 (although 2 is higher up in preference, it will be less common), as a server you will want to prioritize 1 and 2 over 3 and 4 (eg. for clients only supporting P-256 hybrids).
How would you express both preferences in a single configuration?

[vdukhovni]

Postfix would be an example of a client+server that talks to arbitrary endpoints in both directions. nginx or haproxy will typically talk to a limited/controlled set of endpoints on (at least) one side.

The Postfix smtpd(8) and smtp(8) services are, respectively, a TLS server or client only. Only the tlsproxy(8) service can be both, but one can configure multiple instances of tlsproxy(8) in master.cf, with different settings if desired:

$ postconf -d tlsproxy_service_name
tlsproxy_service_name = tlsproxy

But for either example I'm aware of only a single setting to control supported groups for both directions at once, not separately.

This is not a problem for Postfix, settings can be per-service in master.cf

Example group list: (1) X25519+MLKEM768, (2) P-256+MLKEM768, (3) X25519, (4) P-256 As a client you will want to send key_share for 1 and 3 (although 2 is higher up in preference, it will be less common), as a server you will want to prioritize 1 and 2 over 3 and 4 (eg. for clients only supporting P-256 hybrids). How would you express both preferences in a single configuration?

In Postfix, you'd configure one setting for smtpd(8) and a different one for smtp(8), and configure associated tlsproxy(8) instances if applicable.

[ghen2]

@vdukhovni yes I know that (and I do use such smtp/smtpd specific overrides), but in general tls_eecdh_auto_curves applies to all processes - and has a single default value which should cover the typical use cases.

It's just an example of one application (I didn't say one process) which acts as both TLS client and server.

[vdukhovni]

@vdukhovni yes I know that (and I do use such smtp/smtpd specific overrides), but in general tls_eecdh_auto_curves applies to all processes - and has a single default value which should cover the typical use cases.

It's just an example of one application (I didn't say one process) which acts as both TLS client and server.

OK, yes, in some plausibly realistic, though also plausibly uncommon, situations the syntax desirable for clients might clash with the syntax that is desirable for servers.

And therefore, we'd need to have a (! perhaps) prefix for server-side "more equal than others" groups, and a separate prefix (perhaps +) for groups to include in client keyshares, with both used for the same group when appropriate.

[BugOfBugs]

#21633 (comment)
@openssl is bug. Marks comment "off topic". Deleted 3 times.
Deleted this comment too:
#21633 (comment)
#21633 (comment)
Essential. Must unhide.
@ajbozarth must not commit or pull under "rags" without resolution.
They ignore my comment there that create bug.

[t8m]

@BugOfBugs You keep spamming issues with off topic comments. Please refrain from that!

There is nothing wrong with having a draft PR against some issue even if the discussion in the issue is not finished/resolved.