Yeah, if it's feasible to list out the exceptions, this seems a nice way to get out of this mess.
Although I think one of the SHA-2 family should be the hash for the existing channel binding. SHA-3 is slow, and every TLS stack will have SHA-2 available, in a way that they won't for SHA-3. While PQ algorithms regrettably use SHA-3, it may be internal to the PQ implementation. (The really PQ implementations even need a funny multiple-hashes-in-parallel version, so the code sharing opportunity is less than one might think.) Whereas SHA-2 is used directly at the KDF level in TLS. More importantly, it is already a dependency of existing users of that channel binding. If we're moving to a model where we have new hash-specific channel bindings, those who want something in the SHA-3 family can use tls-server-end-point-SHAKE256. David On Fri, Oct 31, 2025, 00:07 Nico Williams <[email protected]> wrote: > In retrospect what we should have done is specified > > tls-server-end-point-<hash> > > and left it as a problem for apps to negotiate one of these if ever they > should have to. > > Perhaps we should do for now is something like update RFC 5929 and the > registraion of tls-server-end-point to list the digest alg to use for > existing signature algs for which TSEP is working today, then say to use > SHAKE256 for all others. > > And perhaps we should specify tls-server-end-point-SHAKE256 as well > while we're at it. > > Nico > -- > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
