Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate - Mailing list pgsql-bugs

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