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