On Thu, Feb 09, 2023 at 02:22:28PM -0800, Jacob Champion wrote:
> +1. I'm still coming up to speed on RSA-PSS and the conversation at
>
> https://github.com/openssl/openssl/issues/15477
>
> but it makes me really uncomfortable to fail open rather than shut in
> this case, as part of a backport.
I could get that some users would want to be able to use such certs,
though. At least we have one such user as of this thread.
>>> Unfortunately, RFC 5929 is very clear:
>>> "if the certificate's signatureAlgorithm uses no hash functions or
>>> uses multiple hash functions, then this channel binding type's
>>> channel bindings are undefined at this time (updates to is channel
>>> binding type may occur to address this issue if it ever arises)."
>>>
>>> I understand from this sentence that if a certificate has no hash
>>> functions, then there's nothing you can do about it.
>
> But we also don't have to proceed as if everything is okay.
The RFC is kind of silly here? It just looks like a wording to give
a lot of freedom about future changes, dropping the responsibility
down to folks using it.. Reading the thread you mentioned, it looks
like even the OpenSSL folks are confused by the choice to have, and
that libcrypto should have little knowledge about which hash type to
pass down depending on the cert type, still they are enforcing the
hash type to use for some cert types.
>>> So as much as I'd like to be aggressive and potentially enforce the
>>> use of SHA256 to compute the certificate hash, what you are doing is
>>> RFC-compliant.
>>
>> Yeah, it seems silly to use anything else than SHA-256, given that
>> SCRAM-SHA-256 is totally dependent on the security of SHA-256 anyway.
>
> 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 the second part of the patch that makes me uncomfortable,
actually. If there is a SASL mechanism that supports channel binding
with a hash higher than SHA-256, the default would likely be such a
hash for functions that are weaker. For example, SCRAM-SHA-512-PLUS
would enforce SHA-512 as hash function when a cert is linked to MD5,
SHA-1 or SHA-256. So, there is a possibility that we need to compile
the hash of a certificate depending on the mechanism name, which is
known at authentication time. As proposed, the patch moves the
compilation at TLS init time. It should not make reloads much slower,
but removes the possibility to switch on-the-fly depending on the
mechanism name received from the client. It is not a problem with
only SCRAM-SHA-256 supported, but could become one in the future.
> Knee-jerk reaction: this departure feels unnecessary since Gunnar's
> certificate does in fact contain a hash algorithm...
What do you mean by Gunnar here?
--
Michael
