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

[Nico Williams <[e-mail]>]

A post [0] to the [e-mail] 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
--