On 10/29/25 11:01 AM, Sophie Schmieg wrote:
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
No no no absolutely not. The 'hash' of mu isn't a pure SHAKE256, it
contains ml-dsa specific differences. If you were to identify the hash,
you would probably call it ml-dsa-hash, but to use that for anything
other calculating 'mu', then you have broken ml-dsa.
In short 'mu' is an implementation optimization, it should not show up
in any protocol spec. It should not be assumed to be universally
implemented.
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 [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
