[TLS] Re: tls-server-end-point channel binding for ML-DSA

[David Benjamin <[e-mail]>]

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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>