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

[Deirdre Connolly <[e-mail]>]

Thank you for the review, I think all of these comments are now addressed
in version 10: https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/10/

On Tue, Sep 1, 2026 at 2:06 AM Ketan Talaulikar via Datatracker <
[e-mail]> wrote:

> 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>
>
>
>
>