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

[Heikki Linnakangas <[e-mail]>]

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?


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