Message-ID: <687f8e73-e511-6994-c2e2-3cc55633fab6@iki.fi>
Date: Fri, 10 Feb 2023 11:33:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss
 signature) server certificate
Content-Language: en-US
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <jchampion@timescale.com>, gunnar.bluth@pro-open.de,
 pgsql-bugs@lists.postgresql.org
References: <17760-b6c61e752ec07060@postgresql.org>
 <b27b9b96-ea65-2ed1-d632-c5ab55713b06@iki.fi>
 <584842ed-e476-6bac-bb36-2aec204e9eef@iki.fi> <Y+St0GKY9FsTTJ1U@paquier.xyz>
 <07e810b5-ea15-87ac-1745-e765e426062e@iki.fi>
 <CAAWbhmh5LiE16nLZcjBjTACzSp4vCJsuiQLsHmzFKdMEncHKdg@mail.gmail.com>
 <Y+V3p2k6yBUWm9N5@paquier.xyz> <9f193dd6-e1c5-fb20-ea90-0e6d03760be8@iki.fi>
 <Y+Xk8N/atQixeE2/@paquier.xyz>
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <Y+Xk8N/atQixeE2/@paquier.xyz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/687f8e73-e511-6994-c2e2-3cc55633fab6%40iki.fi>
Precedence: bulk

On 10/02/2023 08:32, Michael Paquier wrote:
> On Fri, Feb 10, 2023 at 02:24:12AM +0200, Heikki Linnakangas wrote:
>>>> How will this evolve when SCRAM-SHA-512 is implemented? Do you
>>>> plan to upgrade the undef-hash in that case to SHA-512?
>> 
>> Yes, that's what I had in mind. Or for SCRAM-SHA-512, we could go
>> further and define it as "always use SHA-512", because we wouldn't
>> need to worry about backwards compatibility anymore.
> 
> Hmm.  There is a risk of breakage here with older versions of libpq 
> because we'd still need to support both 256 and 512, no?  Or do you 
> mean to drop SCRAM-SHA-256 and do a drop-in replacement with 
> SCRAM-SHA-512?  Doing that in the server may be fine, not in libpq. 
> As long as you control that with the channel binding name, there 
> should be enough control I guess.

We would still support for SCRAM-SHA-256-PLUS in client and server. But 
*if* the server supports and advertises SCRAM-SHA-512-PLUS as a 
supported mechanism, and the client supports and selects it, then with 
SCRAM-SHA-512-PLUS, we could always use SHA-512 as the hash algorithm 
for the channel binding.

Yeah, a MITM could force a downgrade from SCRAM-SHA-512 to 
SCRAM-SHA-256, by modifying the list of supported SASL mechanisms that 
the server sends. Then again, usually the server would not advertise 
both SCRAM-SHA-256 and SCRAM-SHA-512, because pg_role contains only one 
password verifier. Unless we change that too. I don't have a solution 
for these issues right now, but they are not related to channel binding.

The point is that if we add a new SASL mechanism, like 
SCRAM-SHA-512-PLUS, we are free to define how to calculate the 
certificate hash with that mechanism however we want, without breaking 
backwards compatibility.

> So, using a new channel binding name with
> tls-server-end-point-sha-256 is actually the way to violate the RFC,
> while tls-server-end-point still tries to stick with it?

Correct.

> I am not sure if there's much benefit in a second channel binding,
> enforcing SHA-256 for undefined signatures could just be better, and
> simpler. :)

The benefit is that it's more explicit, which helps to reduce the 
confusion. As new signature algorithms are invented in the future, who 
knows what OBJ_find_sigid_algs() in different versions of OpenSSL, or 
other TLS libraries, will do with them. With a new 
"tls-server-end-point-sha-256" channel binding type, it's clear.

> There be a risk of a downgrade attack here, where the client could 
> feign the server to do a SHA-256 computation where SHA-512 or higher 
> should be used.  Or, if the server certificate has a hash function
> but the client feigns in not knowing that, do you mean to go through
> a mock authentication in this case and fail?

Let's always allow tls-server-end-point-sha-256 in the server. The point 
of channel binding is to protect the client from a MITM. The client 
chooses the channel binding type to use, so a MITM cannot force it to 
downgrade.

To be honest, I am not at all worried about losing security by using 
SHA-256 instead of SHA-512 or whatever else is in the certificate. If 
you don't trust SHA-256, you wouldn't be comfortable using SCRAM-SHA-256 
at all.

"tls-server-end-point-sha-256" is simpler than the current rules, so new 
client implementations that are not worried about 
backwards-compatibility might not bother with the current rules at all, 
and only implement "tls-server-end-point-sha-256".

- Heikki