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

[Ketan Talaulikar <[e-mail]>]

Thank you Deirdre.


On Thu, Sep 3, 2026 at 12:51 AM Deirdre Connolly <[e-mail]>
wrote:

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