Re: [CHANNEL-BINDING] New channel binding type similar to "tls-server-end-point"

[Alexey Melnikov <[e-mail]>]

Hi Heikki,

On 10/02/2023 15:01, Heikki Linnakangas wrote:
> Currently, "tls-server-end-point" channel binding type is undefined if 
> the server certificate's signatureAlgorithm field does not 
> unambiguously specify a hash function. See [RFC5929], section 4.1.
>
> I propose a new channel binding type, 
> "tls-server-end-point-auth-hash". It is the same as 
> "tls-server-end-point", but instead of deriving the hash function from 
> the certificate's signatureAlgorithm, it uses the same hash function 
> that is used by the authentication method. So when it is used with 
> SCRAM-SHA-256, for example, SHA-256 is used.
>
> If I'm reading correctly between the lines in RFC5929, the reason that 
> "tls-server-end-point" was defined to use the hash algorithm in the 
> signatureAlgorithm was to provide hash agility. However, when used 
> with an authentication mechanism like SCRAM-SHA-256, that agility 
> seems pointless; the security relies on SHA-256 anyway. This proposed 
> variant has the advantage that it can be used with all TLS 
> certificates, regardless of the signatureAlgorithm, and you don't need 
> any extra hash functions other than the one that's used by the 
> authentication mechanism anyway.
>
> I'm not familiar with the IETF processes. What do I need to do to get 
> that registered?

The IANA registry 
<https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml> 
states that the registration procedure is Expert Review. So basically 
you can email IANA [e-mail] (or use the web form 
https://www.iana.org/protocols/apply) to request a registration.

Best Regards,

Alexey

>
>
> Background:
>
> PostgreSQL supports the SCRAM-SHA-256-PLUS authentication with 
> "tls-server-end-point" channel binding. However, because it is 
> undefined for some certificates, channel binding cannot be used with 
> ED448 and ED25519 certificates, for example. We would like to support 
> channel binding with all server certificates.
>
> A user ran into this with an rsassaPss certificate, and for that we 
> could perhaps derive the hash algorithm by looking into the 
> rsaSsaParams field of the certificate, in addition to 
> signatureAlgorithm. But that seems like over-interpreting RFC5929, and 
> doesn't solve the general case anyway. See discussion on the 
> PostgreSQL mailing list: 
> https://www.postgresql.org/message-id/687f8e73-e511-6994-c2e2-3cc55633fab6%40iki.fi
>
> PS. The reason that PostgreSQL implements "tls-server-end-point" and 
> not "tls-unique", even though RFC 5802 clearly says that a server MUST 
> support "tls-unique" if any channel binding type is supported, is that 
> when it was implemented, the future of "tls-unique" was unclear. There 
> were security concerns with it and TLS renegotiation, and it was 
> undefined for TLSv1.3. Also, not all TLS implementations provided an 
> interface to export the material needed for "tls-unique". There has 
> been discussion on implementing the new "tls-exporter" binding with 
> TLSv1.3, but even if we add support for that, we will likely still 
> continue to support "tls-server-end-point" for a long time.
>
> - Heikki
>
> _______________________________________________
> CHANNEL-BINDING mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/channel-binding