Re: Channel binding for post-quantum cryptography

On Mon, Oct 20, 2025 at 05:06:12PM +0900, Michael Paquier wrote:
> On Mon, Oct 20, 2025 at 09:12:52AM +0200, Filip Janus wrote:
> > The problem is caused by a difference between the currently used algorithms
> > and post-quantum ones. For example, commonly used algorithms like RSA have
> > a defined digest algorithm, but ML-DSA does not.
> >
> > PostgreSQL's channel binding implementation expects all signature
> > algorithms to have a traditional digest mapping, but post-quantum
> > algorithms such as ML-DSA use their hash function internally as part of the
> > signature process.
>
> Noted.
>
> > As a result, the connection fails with the following error:
> >
> > could not find digest for NID UNDEF
> >
> > The issue can be worked around by disabling channel binding.
> >
> > Although the RFC is not entirely clear on how to handle this situation, in
> > my patch I propose using SHA-256 as the default digest in such cases.
>
> Based on the RFC at [1], we have indeed:

RFC 5929 co-author here. We should take this to the IETF TLS WG mailing
list and update RFC 5929 and the tls-server-end-point registraion to fix
this.

Options in the case that the certificate's signature algorithm does not
have a digest associated with it include:

- use the whole certificate un-digested (but smallish CB data is
somewhat useful)

or

- else specify the use of a digest negotiated by TLS (except that this
is rather inconvenient since it means extracting that metadata from
the connection)

or

- we could specify `tls-server-end-point-<digest>` channel bindings
(but the the PG client and server would have to negotiate _that_)

or

- we could specify a disgest for this purpose for each signature
algorithm that does not have an associated digest

The app could pick a digest by itself, but if the app were using a TLS
library API to get at the `tls-server-end-point` CB as such then that
wouldn't help unless there was also an API to get at the raw server
certificate.

Maybe there are more options still. But we're not likely to solve this
problem here. This really belongs on the IETF TLS WG mailing list.

Nico
--