Hi,
I read the draft and I support its publication.
Nits & typos:
Section 5:
s/{KOBEISSI26}/[KOBEISSI26]
I would place the sentence:
Formal analysis has also shown that hybrid key
establishment (e.g., [HYBRID], [ECDHE-MLKEM]) provides compositional
security; the exchange remains secure as long as at least one of the
component algorithms is unbroken.
in a separate para, since all the other text in this para is concerned
with ML-KEM and this sentence is concerned with hybrid mechanisms.
Section 7.2
s/Post-Quantum {TLS} 1.3 Handshake from {CPA}-Secure {KEMs}/ Post-Quantum TLS
1.3 Handshake from CPA-Secure KEMs
Regards,
Valery.
> -----Original Message-----
> From: Joseph Salowey via Datatracker <[email protected]>
> Sent: Wednesday, June 24, 2026 6:00 PM
> To: [email protected]; [email protected]; [email protected]
> Subject: [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
>
> This message initiates a new Working Group Last Call for
> draft-ietf-tls-mlkem[1], which defines standalone ML-
> KEM key establishment for TLS 1.3. The main question before the working group
> is: "Should the working group
> publish a document specifying stand alone ML-KEM?". If there is rough
> consensus then we will push to refine and
> publish the document; otherwise, we will stop discussing the draft and not
> progress it. Please respond to this call
> indicating whether you support publishing a document specifying a stand alone
> ML-KEM. Please refrain from
> further discussion on this topic as most arguments have been discussed
> multiple times.
>
> Why are we holding this consensus call now?
>
> Significant developments have occurred both within this document and in the
> broader TLS ecosystem to address
> the concerns raised in the last WGLC. Therefore, the third consensus call is
> warranted. We ask the working group
> to consider document publication in light of these recent changes:
>
> - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a separate
> consensus call, the WG agreed to
> promote the X25519MLKEM768 hybrid group to Recommended: Y in the IANA
> registry. Consequently, the IANA
> registry will reflect a clear community preference for a hybrid because
> Recommended: Y clearly indicates this while
> the standalone ML-KEM groups defined in this draft remain Recommended: N. The
> updated security
> considerations in [1] reference the IANA registry to emphasize this
> preference.
>
> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG recently
> reached consensus to explicitly prohibit
> key share reuse across connections in TLS 1.3. The new text changes the
> guidance from SHOULD NOT to a strict
> MUST NOT. This resolves the concerns regarding static key reuse and its
> associated privacy and forward-secrecy
> risks for ML-KEM.
>
> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and hybrid KEM
> groups in TLS 1.3. This supports
> other results which show that KEMs are secure when used in TLS 1.3 and that
> hybrid groups are secure even if
> one of the components is compromised.
>
> - Liaisons: We received liaison statements from multiple SDOs including
> O-RAN[2], IEEE 802.11[4] and from
> 3GPP[3] expressing support for the publication of draft-ietf-tls-mlkem as an
> RFC as they rely on the IETF to
> provide a stable normative reference.
>
> Please note that a third-party IPR disclosure exists [5] against this
> document regarding patents related to the
> underlying ML-KEM algorithm. This IPR declaration has not changed since the
> last WGLC. As a reminder, per
> BCP 79, the IETF takes no stance on the validity of patent claims, and the
> working group may decide to proceed
> with a technology despite IPR disclosures if it decides that such use is
> warranted.
>
> Conduct Reminder: Given the heated nature of previous discussions on this
> topic, participants are strongly
> reminded to adhere to the IETF Code of Conduct (BCP 54) and the TLS WG's Mail
> List Procedures. Keep
> feedback professional, technical, and focused on the document's text.
>
> This working group last call will end on 2026-07-08.
>
> Joe and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> [2] https://datatracker.ietf.org/liaison/2198/
> [3] https://datatracker.ietf.org/liaison/2151/
> [4] https://datatracker.ietf.org/liaison/2148/
> [5]
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
