On Wed, Oct 29, 2025 at 8:36 AM Kampanakis, Panos <[email protected]> wrote: > > 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 😉
Would everyone come to that same conclusion though? Might be an errata or a short doc clarifying is needed. > > > -----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] -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
