Hi Nico, Interesting. Indeed, it seems that currently ML-DSA server certs would appear to fall under the "undefined hash subcase" because they don't have an obvious digest.
But strictly speaking, ML-DSA X.509 certs (draft-ietf-lamps-dilithium-certificates) have a built-in hashing which SHAKE256 hashes the public key tr and the message (TBScert). This produces the mu value used in the ML-DSA Sign algorithm that produces the cert signature. So, I would argue that (f) ML-DSA certs fall under the second bullet which prescribes reusing the cert signature hash, and that hash is SHAKE256. Case closed, no more work required 😉 -----Original Message----- From: Nico Williams <[email protected]> Sent: Wednesday, October 29, 2025 12:48 AM To: [email protected] Subject: [EXTERNAL] [TLS] tls-server-end-point channel binding for ML-DSA CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. A post [0] to the [email protected] mailing list 8 days ago points out that tls-server-end-point channel binding for ML-DSA is undefined. [0] https://www.postgresql.org/message-id/CAFjYY%2BJCCQeh03nzVG6Rs9MUgU_kOvhMbNaaS6kn_c4CcAZkTg%40mail.gmail.com Basically per RFC 5929, section 4.1, if the signing algorithm does not have an associated digest -or has more than one- then tls-server-end-point channel bindings (let's call that TSEP CB) for the connection is undefined: | o if the certificate's signatureAlgorithm uses no hash functions or | uses multiple hash functions, then this channel binding type's | channel bindings are undefined at this time (updates to is channel | binding type may occur to address this issue if it ever arises). ML-DSA indeed does not hash the to-be-signed data, though it does use _two_ hash functions internally (SHAKE128 and SHAK256). The HashML-DSA variants do use a hash function (each) to digest the to-be-signed data, but using HashML-DSA just to have TSEP be defined is not satisfying because not using ML-DSA to sign certificates is not exactly an acceptable solution here. Surely there will be other signature algorigthms for which TSEP CB will not be defined. What can we do to fix this? Options include: a) update RFC 5929 to use some other hash function from the TLS handshake in this case b) update RFC 5929 to specify a default hash function for such cases (unsatisfying unless the "hash" function were the identity function) c) update RFC 5929 to create an IANA registry mapping signature algorithms to hash function for use in TSEP CB d) define TSEP-<HASH-FUNCTION> CB types and let apps negotiate CB types (also unsatisfying: because apps generally do not negotiate CB types) e) ask CFRG, NIST, etc, to always specify a function for use in TSEP when specifying any new signature algorithms (this could take a long time to achieve) f) ?? (a), (b) using the identity function, and (c) all seem workable. (d) is right out, and (e) could take forever, though (e) might be desirable for other reassons. Advice? Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
