I support publication of draft-ietf-tls-mlkem, as Informational, the Intended
RFC status proposed.
It will be more convincing if [KOBEISSI26] will be reviewed by FATT experts or
even published a little later.
Two minor comments:
- In Section 5, [KOBEISSI26] is cited as {KOBEISSI26}.
- In Section 7.2, No author name for [KOBEISSI26].
Guilin
From: Deirdre Connolly <[email protected]>
Sent: Thursday, 25 June 2026 1:28 am
To: Schäfer, Pascal <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: [TLS] Re: [External] WG Last Call: draft-ietf-tls-mlkem-08 (Ends
2026-07-08)
> I saw an "and and", which should probably just an "and".
Fixed:
https://github.com/tlswg/draft-ietf-tls-mlkem/commit/7d823d27ef341ee79af3a910e5327ef8ebcfad61
On Wed, Jun 24, 2026 at 12:04 PM Schäfer, Pascal
<[email protected]<mailto:[email protected]>> wrote:
I support the publication of this document.
Only one editorial comment beside of the other mentioned editorial comments:
In the abstract I saw an "and and", which should probably just an "and".
-----Original Message-----
From: Joseph Salowey via Datatracker <[email protected]<mailto:[email protected]>>
Sent: Mittwoch, 24. Juni 2026 17:00
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [External] [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends
2026-07-08)
WARNING: External email. Be vigilant with links, attachments, and requests.
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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7Xp19ojzQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-tls-mlkem/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7Xp19ojzQ$>
[2]
https://urldefense.com/v3/__https://datatracker.ietf.org/liaison/2198/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7UVzVFYJQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/liaison/2198/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7UVzVFYJQ$>
[3]
https://urldefense.com/v3/__https://datatracker.ietf.org/liaison/2151/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7V-27j4vg$<https://urldefense.com/v3/__https:/datatracker.ietf.org/liaison/2151/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7V-27j4vg$>
[4]
https://urldefense.com/v3/__https://datatracker.ietf.org/liaison/2148/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7VaUHPDRw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/liaison/2148/__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7VaUHPDRw$>
[5]
https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7XeMmnQZw$<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem__;!!OrxsNty6D4my!6IJnS7RUmoEUptkioAYza6Ne1ruwc-jgBR1Opv9lUfXct3Vb7BGgc4NmlSdoEg7PhZRHWLPUQGPQD7XeMmnQZw$>
_______________________________________________
TLS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
________________________________
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise confidential information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the e-mail by you is prohibited. Where allowed by local law, electronic
communications with Accenture and its affiliates, including e-mail and instant
messaging (including content), may be scanned by our systems for the purposes
of information security, AI-powered support capabilities, and assessment of
internal compliance with Accenture policy. Your privacy is important to us.
Accenture uses your personal data only in compliance with data protection laws.
For further information on how Accenture processes your personal data, please
see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________
www.accenture.com<http://www.accenture.com>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
