The other option is using external-µ as the hash function, but really the issue is that the hash function is always part of the signature scheme, and attempts at considering them separate are fraught with vulnerabilities. So my preference would be exporter-based channel binding
On Wed, Oct 29, 2025 at 9:57 AM David Benjamin <[email protected]> wrote: > Ah yeah, if the identify function works, that's easy enough. Although, one > reason to keep it small is so you don't have to hold on to the certificate > after the handshake, across resumptions, and in tickets. > > Most TLS stacks do hold on to it today, but they're getting bigger with > PQ. I've been musing on APIs where the certificate isn't retained, and > instead you retain only that's needed for the application. (After you've > verified the certificate, the signature is never used again. After you've > verified CertificateVerify on the initial connection, the public key is > never used again. And so on.) In that model, if the channel binding might > be used later in the connection lifetime, or across resumption, keeping it > small may be worthwhile. > > ...or perhaps we should be using an exporter-based channel binding and > move on. ;-) > > On Wed, Oct 29, 2025 at 12:34 PM Nico Williams <[email protected]> > wrote: > >> On Wed, Oct 29, 2025 at 12:10:59PM -0400, David Benjamin wrote: >> > The rules in RFC 5929 are quite unfortunate because it means that the >> > application needs to actually recognize the signature algorithm, [...] >> >> +1. I think we wanted the TSEP CB data to be "small". That was >> misguided. >> >> Though it need not be the application so much as the TLS implementation, >> which can provide an accessor for getting at the CB data for any >> supported CB type for a given connection. >> >> > If I had a time machine, I would say the right answer would be that >> > tls-server-end-point is completely disconnected from the certificate >> > signature algorithm and instead is either a fixed hash (SHA-256 is >> fine), >> > or determined from the TLS connection state, not the certificate. I >> don't >> > have a time machine, but that might suggest updating the RFC to say: >> >> Or just the identity function. >> >> > 1. If the certificate signature algorithm is {one of these legacy >> entries}, >> > use {the hash algorithm that the old spelling provide} >> > 2. Otherwise, it is SHA-256[*] and we move on with life >> > >> > [*] Or the cipher suite PRF hash if you like, but the channel binding >> > already has a hardcoded SHA-256 dependency. If SHA-256 ever falls, >> defining >> > a new channel binding will be the least of our headaches. >> >> But it would be one of many headaches. >> >> Nico >> -- >> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
