Re: BUG #17760: SCRAM authentication fails with "modern" (rsassaPss signature) server certificate

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