[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[Eric Rescorla <[e-mail]>]

On Tue, Nov 25, 2025 at 4:06 PM Benjamin Kaduk <bkaduk=
[e-mail]> wrote:

> # Ben Kaduk's review of draft-ietf-tls-mlkem-05
> CC @kaduk
>
> I do not support publication of this document at this time; see the
> "discuss" points for specific items that IMO should be blocking.  (I'm not
> an AD anymore, of course, so they aren't actually blocking just because I
> think they should be, but this is a handy review template...)
>
> ## Discuss
>
> ### KeyShare semantics
>
> In §4.2 when we write
>
> > The KeyShareClientHello includes a list of KeyShareEntry structs that
> represent the key establishment algorithms the client supports. For each
> parameter of ML-KEM the client supports, the corresponding KeyShareEntry
> consists of a NamedGroup that indicates the appropriate parameter, and a
> key_exchange value that is the pk output of the KeyGen algorithm.
>
> that misrepresents the semantics of the "key_share" extension (and I
> assume we are not attempting to redefine core TLS 1.3 semantics).
> "key_share" contains cryptographic parameters but makes no indication about
> algorithms that the client (or server) supports -- that role is fulfiled by
> "supported_groups".
>

Oh, good catch. Is there a reason that this paragraph should exist at all?
Don't the grafs below
starting with "For the ..." carry all the information you need to know?

In fact, I think we could omit most of this section, because it's just
redundant with
RFC 8446.





> (It's also a bit strange to have prose describing what KeyShareClientHello
> contains without corresponding prose about the KeyShareServerHello, but
> since we're not actually redefining what TLS 1.3 says I guess we don't need
> to.  But by that measure we don't need to have prose about
> KeyShareClientHello, either.)
>

Agreed. It's just an opportunity for confusion.



## Comments
>
> ### Presumption of migrating beyond hybrids
>
> In §1.1 we note that "Having a purely post-quantum (not hybrid) key
> establishment option for TLS 1.3 is necessary for migrating beyond hybrids
> and for users that want or need post-quantum security without hybrids"
> which is true if we presuppose that there is a need to migrate beyond
> hybrids and user desire to achieve post-quantum security without hybrids,
> but does not really justify those presuppositions.  I think we should try
> to avoid value judgements (which may be hard to achieve consensus on), and
> thus that we should rather say something like "This document defines
> key-establishment options for TLS 1.3 that use solely post-quantum
> algorithms, without a hybrid construction that also includes a traditional
> cryptographic algorithm".
>

I concur with Ben. This seems like a much more straightforward factual
statement.

-Ekr