From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Erica Zhang <ericazhangy2021(at)qq(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, jkatz(at)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add support to TLS 1.3 cipher suites and curves lists |
Date: | 2024-12-11 19:13:05 |
Message-ID: | Z1nkQaZpw4jN00wC@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 11, 2024 at 12:47:01PM -0500, Tom Lane wrote:
> Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
>> On Wed, Dec 11, 2024 at 9:11 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>>> Sorry for chiming in so late here, but I was a little surprised to see the
>>> TLS version in the GUC name. ISTM this would require us to create a new
>>> GUC for every new TLS version, or explain that ssl_tls13_ciphers isn't just
>>> for 1.3.
>
>> I agree it's not ideal. But part of the problem IMO is that we might
>> actually _have_ to introduce a new GUC for a future TLS 1.4, because
>> we have no idea if the ciphersuites will change incompatibly again. (I
>> hope not, but they did it once and they could do it again.)
>> If 1.4, or 2.0, or... 4? [1] comes out later, and it turns out to be
>> compatible, we could probably add a more appropriate alias then. (For
>> now, just as some additional data points, both Apache and Curl use
>> "1.3" or "13" in the configuration as a differentiator.) Do you have a
>> different naming scheme in mind?
In a vacuum, I would've probably voted for ssl_cipher_suites since it is
reasonably descriptive and version-independent. It's true that we'd need
lots of documentation to explain which parameter is used for which TLS
version, but I think we need that regardless of the parameter name.
> Oh yay, another naming problem :-(. I think that neither "ciphers"
> vs. "cipher suites" nor "ssl_ciphers" vs. "ssl_ciphers_tlsv13" is
> going to convey a lot to the average person who's not steeped in
> TLS minutiae. However, following the precedent of Apache and Curl
> seems like a good answer --- that will ensure that at least some
> part of the internet-using world has seen this before. So I guess
> I'm +0.5 for the ssl_ciphers_tlsv13 answer, at least out of the
> choices suggested so far.
I wasn't aware that other projects were including the version, too. IMHO
that's a fair argument for the current name, if for no other reason than
we'll be in good company if/when things change. All things considered, I'd
probably still vote for something like ssl_cipher_suites, but I'm happy to
consider the matter resolved if we've given it some thought and decided to
stick with ssl_tls13_ciphers.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2024-12-11 19:13:23 | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Previous Message | Matheus Alcantara | 2024-12-11 19:04:41 | Re: SCRAM pass-through authentication for postgres_fdw |