[TLS] Ketan Talaulikar's No Objection on draft-ietf-tls-mlkem-09: (with COMMENT)

[Ketan Talaulikar via Datatracker <[e-mail]>]

Ketan Talaulikar has entered the following ballot position for
draft-ietf-tls-mlkem-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to the authors and the WG for their work on this document.

Please find below some comments on this document inline in the idnits output
of v09. Look out for the <EoRv09> tag at the end to ensure you are seeing the
full review.

132	   The KEMs are defined as NamedGroups, sent in the supported_groups
133	   extension.  Section 4.3.7 of [RFC9846]

<nit> The second sentence is a fragment. Perhaps:

The KEMs are defined as NamedGroups and sent in the supported_groups extension
defined in Section 4.3.7 of [RFC9846].

201	   This document defines standalone ML-KEM key establishment for TLS
202	   1.3.  Use of KEMs for key agreement in TLS 1.3 has been analyzed in
203	   multiple settings and security models [DOWLING] [KEMTLS] [HV22]
204	   [CHSW22] [CZCJWH25] [ZJZ24]; ML-KEM's IND-CCA security exceeds the
205	   requirements for ephemeral key establishment [GHS25] [RFC9846].
206	   Multiple formal analyses, including pen-and-paper computational
207	   proofs and machine-checked symbolic analysis using ProVerif
208	   [KOBEISSI26], demonstrate that replacing Diffie-Hellman with an IND-
209	   CCA-secure KEM preserves the security properties of the TLS

<nit> Please expand IND-CCA at first use.

210	   handshake.  Formal analysis has also shown that hybrid key
211	   establishment (e.g., [HYBRID], [ECDHE-MLKEM]) provides compositional
212	   security: the exchange remains secure as long as at least one of the
213	   component algorithms is unbroken [BJ24] [CPWB25].

<nit> Both cited Internet-Drafts have now been published. Please update
[HYBRID] to RFC 9954 and [ECDHE-MLKEM] to RFC 10024.

233	   The disclosure of the output(s) of an insecure random number
234	   generator (RNG) when used in TLS and other protocols can be used in
235	   an attack to compromise the state of the insecure RNG itself as
236	   described in [DUALEC-TLS].  The encapsulation randomness in ML-KEM is
237	   an additional place where raw RNG output may be disclosed, therefore
238	   it is important to follow the RNG guidance in [FIPS203] and
239	   [RFC9846].  Implementers can choose to implement mechanisms from

<nit> The citation above uses [DUALEC-TLS], while the reference entry is
defined as [DUALECTLS]. Please use one reference key consistently.

244	   This document requests/registers three new entries to the TLS Named
245	   Group (or Supported Group) registry, according to the procedures in
246	   Section 6 of [RFC9847].
248	   +======+=============+=======+=============+=========+=============+
249	   |Value | Description |DTLS-OK| Recommended |Reference| Comment     |
250	   +======+=============+=======+=============+=========+=============+
251	   |0x0200| MLKEM512    |Y      | N           |This     | FIPS 203    |
252	   |      |             |       |             |document.| version of  |
253	   |      |             |       |             |         | ML-KEM-512  |
254	   +------+-------------+-------+-------------+---------+-------------+
255	   |0x0201| MLKEM768    |Y      | N           |This     | FIPS 203    |
256	   |      |             |       |             |document.| version of  |
257	   |      |             |       |             |         | ML-KEM-768  |
258	   +------+-------------+-------+-------------+---------+-------------+
259	   |0x0202| MLKEM1024   |Y      | N           |This     | FIPS 203    |
260	   |      |             |       |             |document.| version of  |
261	   |      |             |       |             |         | ML-KEM-1024 |
262	   +------+-------------+-------+-------------+---------+-------------+

<major> These entries are already registered in the TLS Supported Groups
registry. This same issue has come up in the IANA review, which confirms that
the entries already exist and that the remaining action is to update their
Reference fields.

Please replace the request to register new entries with an instruction to
update the Reference fields of the existing entries, and use the registry's
exact name, TLS Supported Groups. The registry presents these values as
decimal 512, 513, and 514; please use that presentation or show decimal and
hexadecimal together.

398	   Thanks to Douglas Stebila for consultation on the draft-ietf-tls-
399	   hybrid-design design, and to Scott Fluhrer, Eric Rescorla, John Preuß
400	   Mattsson, Martin Thomson, and Rebecca Guthrie for reviews.

<nit> There is a duplicated use of design here. Perhaps:

"design of RFC 9954"

<EoRv09>