Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGcIj-00F9Sc-B1 for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Jun 2024 10:30:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sGcIh-00AYi6-4e for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Jun 2024 10:30:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGcIg-00AYhy-NG for pgsql-hackers@lists.postgresql.org; Mon, 10 Jun 2024 10:30:55 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGcIe-000cCt-4G for pgsql-hackers@lists.postgresql.org; Mon, 10 Jun 2024 10:30:54 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id C67443022D7A for ; Mon, 10 Jun 2024 12:30:47 +0200 (CEST) Received: from s980.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id B52482E2888E; Mon, 10 Jun 2024 12:30:47 +0200 (CEST) Received: from s470.loopia.se (unknown [172.22.191.5]) by s980.loopia.se (Postfix) with ESMTP id B2DB122016E3; Mon, 10 Jun 2024 12:30:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1] autolearn=disabled Authentication-Results: s470.loopia.se (amavisd-new); dkim=pass (2048-bit key) header.d=yesql.se Received: from s981.loopia.se ([172.22.191.5]) by s470.loopia.se (s470.loopia.se [172.22.190.34]) (amavisd-new, port 10024) with UTF8LMTP id BPXrCVE8-9RR; Mon, 10 Jun 2024 12:30:47 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.193 Received: from smtpclient.apple (customer-89-255-232-193.stosn.net [89.255.232.193]) (Authenticated sender: daniel@yesql.se) by s981.loopia.se (Postfix) with ESMTPSA id 2362F22B172D; Mon, 10 Jun 2024 12:30:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yesql.se; s=loopiadkim1707475645; t=1718015447; bh=c8/Mcg/nzF8DlGInAxiHfMcu3L51Og8ES9fuYpAN3II=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GIKsD431Kbzmb6v36phkDBP8TZBs7IjpymkfFdCm+zZ6hU1Rt1uMDB15WW95XskH7 Cs9pxOO/vQyCfmjNFCIkxcXwJ97SWVTpjciYUgPY/kDASvfEAKMv8u884jnOoBYlMY BkR+RlBJc67Dj6tK8Yombrpm8c629dSTo3o83IAC6J9rsobgpMH7Ed1zuMajf9/VYh Nxl1Pp1IQbQ7tbEnHH2AZIUQcqN7kYUM2I5u4wd2AkjezAtk9McHW69aYTKlI//sfG ObRFEMFyu9Vk8Z8K7fCRJoviKc4LIGVuryTkAVl5iFp4HPvEtML1Fif22FddIgvzpX /FZOo5OEMlKnw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Add support to TLS 1.3 cipher suites and curves lists From: Daniel Gustafsson In-Reply-To: Date: Mon, 10 Jun 2024 12:30:36 +0200 Cc: Jacob Champion , Peter Eisentraut , pgsql-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <8AD6972C-7362-4A8D-96AA-6FAC44CE154B@yesql.se> References: To: Erica Zhang X-Mailer: Apple Mail (2.3774.500.171.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 7 Jun 2024, at 19:14, Jacob Champion = wrote: > - Could you separate the two features into two patches? That would > make it easier for reviewers. (They can still share the same thread > and CF entry.) +1, please do. > - The "curve" APIs have been renamed "group" in newer OpenSSLs for a > while now, and we should probably use those if possible. Agreed. While not deprecated per se the curve API is considered = obsolete and is just aliased to the group API (OpenSSL using both the term obsolete = and deprecated to mean the same thing but with very different mechanics is = quite confusing). > - I think parsing apart the groups list to check NIDs manually could > lead to false negatives. =46rom a docs skim, 3.0 allows providers to = add > their own group names, and 3.3 now supports question marks in the > string to allow graceful fallbacks. Parsing the list will likely risk false negatives as you say, but from = skimming the code there doesn't seem to be a good errormessage from = SSL_set1_groups_list to indicate if listitems were invalid (unless all of them were). Maybe = calling the associated _get function to check the number of set groups can be = used to verify what happenend? Regarding the ciphersuites portion of the patch. I'm not particularly = thrilled about having a GUC for TLSv1.2 ciphers and one for TLSv1.3 ciphersuites, = users not all that familiar with TLS will likely find it confusing to figure = out what to do. In which way is this feature needed since this can be achieved with the = config directive "Ciphersuites" in openssl.conf IIUC? If we add this I think we should keep it blank and if so skip setting it = at all falling back on OpenSSL defaults. The below default for the GUC does = not match the OpenSSL default and I think we are better off trusting them on this. + "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256", -- Daniel Gustafsson