Date: Tue, 3 Mar 2026 11:43:10 +0100
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Add ssl_(supported|shared)_groups to sslinfo
Message-ID: <izopeja2suconbqpbswmtto5czajnc4p7rsml5gwwrs56lexaj@kmqdrqiepays>
References: <d57duqvzkxe43oons3jkdq7pj2wacidg7qorxommri74evu3l2@4x53she7mf77>
 <D1EC4B00-9593-488F-916D-090A73E69B4E@yesql.se>
 <CAOYmi+nkT7rkbNd6que0wtz=epOikgBKSDR88DQ=cyNJwiUw8Q@mail.gmail.com>
 <srua2tidoiztaytmxlwjfpjhntxelmxpfta4lhulvlker444yg@sf232zqm3qvs>
 <CAOYmi+k7v6hP5nM7BQdKu37TJFi-X=d7_SDswZBV5q0awxPVYg@mail.gmail.com>
 <qyw7l5ztbqouluctxgbxc2aty43suulka2q4ybpaew4tey7rlw@l66rjb7vxxhk>
 <CAOYmi+=r50Kk1c7A7O8yXwJzALyyqDmQE7FiCZvZmt_3WRBGwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAOYmi+=r50Kk1c7A7O8yXwJzALyyqDmQE7FiCZvZmt_3WRBGwQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/izopeja2suconbqpbswmtto5czajnc4p7rsml5gwwrs56lexaj%40kmqdrqiepays>
Precedence: bulk

> On Fri, Feb 27, 2026 at 04:51:40PM -0800, Jacob Champion wrote:
> >     select * from ssl_group_info();
> >         type    |        name
> >     ------------+--------------------
> >      negotiated | X25519MLKEM768
> >      shared     | X25519MLKEM768
> >      shared     | x25519
> >      supported  | X25519MLKEM768
> >      supported  | x25519
> 
> Hmm, I'm developing strong opinions over something I said I didn't
> feel strongly about. Sorry...

No worries, it's a valuable discussion so far :)

> The type names "negotiated", "shared" and "supported" don't really
> tell me much as an end user. I know, as a dev, that "negotiated" is
> the one that was chosen, "supported" is what the client provided, and
> "shared" is the intersection of the client and server sets. But I
> think it'd be good to choose names that are either based on the
> official TLS specification, or immediately clear to someone who is not
> well-versed in TLS to begin with, as opposed to using OpenSSL's
> internal API names.

Naming is hard of course, but my plan was to stick to short names like
those above, and unwrap them in the documentation:

* Supported: list of named groups supported by the client for key
  exchange in the form of "supported_groups" extension.

  Supported group is the exact terminology used in the TLS spec.

* Shared: lisf of named groups shared with the server side.

  This one actually doesn't appear in the spec. The closest name
  featured is "selected_groups", but only in the context of the retry
  requests. Thus I took this form the OpenSSL docs.

* Negotiated: the group used for the handshake key exchange process.

  Surprsingly, I don't see any exact terminology for this in the TLS
  spec, it just says "the named group for the key being exchanged". The
  name is taken from the OpenSSL documentation.

How does it sound?

> Also, I feel like this is still missing the server side of the Venn diagram.

Indeed, the TLS spec says that the server is permitted to send the
"supported_groups" extension to the client, so this might be
interesting. But it doesn't look like there is any OpenSSL API to get
those, beyond SSL_ctrl, which is not supposed to be called directly.

> Also also: if we later expose a version of this table for the
> ciphersuites or other negotiated parameters, is this how we'd want the
> table to look? What did you care most about when you were debugging?

I don't see why not. The reason why I've started tinkering on that was
only to get the negotiated group. But I'm convinced that, since
PostgreSQL sets the groups extension, it totally makes sense to provide
some API for diagnostig reasons to check what's in there beyond only one
single group.