On Thu, Feb 12, 2026 at 04:51:03PM -0500, Deirdre Connolly wrote:
> Thank you all for reading and replying. I have pushed some changes to the
> GitHub repo based on the discussions so far (not to datatracker yet):
>
> https://github.com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-05..main
>
> (the tlswg.org domain is messed up otherwise i would link the diff based on
> the Editor's draft)
Two comments.
1. The first is mostly a trivial choice of terminology question:
(Motivation):
https://datatracker.ietf.org/doc/html/draft-ietf-tls-mlkem-07#section-1.1
FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum
[RFC9794] key establishment via a lattice-based key encapsulation
mechanism (KEM).
Would ML-KEM be better described as a "NIST standard", or is it better
(as written) to say that FIPS 203 is a "FIPS standard"? Perhaps:
ML-KEM [FIPS203] is a NIST standard for post-quantum [RFC9794] key
establishment via a lattice-based key encapsulation mechanism (KEM).
2. The second, more substantative, comment is about the latest text
below:
The client's shares are listed in descending order of client
preference; the server selects one algorithm and sends its
corresponding share.
This is not accurate, because the server is free to choose a client
supported group for which no keyshare was sent (predicted) in the
initial Client Hello, by returning an HRR with that choice.
And the order of preference is taken from the client's list of supported
groups, not its wire order of keyshares in the keyshare extension
(though the latter order is mandated to match the former):
Supported Groups:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.7
When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports for key exchange, ordered
from most preferred to least preferred.
(Key Share)
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8
This vector MAY be empty if the client is requesting a
HelloRetryRequest. Each KeyShareEntry value MUST correspond to a
group offered in the "supported_groups" extension and MUST appear in
the same order. However, the values MAY be a non-contiguous subset
of the "supported_groups" extension and MAY omit the most preferred
groups. Such a situation could arise if the most preferred groups
are new and unlikely to be supported in enough places to make
pregenerating key shares for them efficient.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
