Hello,
My name is Rob Hunter from the Dutch Ministry of the Interior and Kingdom Relations (minbzk.nl).
I support publication of this document for several reasons. I would like to thank the author and chairs for their efforts in getting this document to its current state. I note that this documents is 'informational' and does not claim to be a 'best practice' document.
- In the Netherlands and within the EU, we have a PQ migration strategy, see chapter 5.3 of [1] that encourages the use of hybrid constructions. If other countries wish to adopt non-hybrids that is their own policy decision and I respect their right to make such decisions.
- EU certification schemes will issue certifications based on EU guidelines. Whilst products might support non-hybrid constructions, EU certifications will probably mandate hybrid constructions by default.
- US certification schemes will issue certifications based on US guidelines. Whilst products might support hybrid constructions, US certifications will probably mandate non-hybrid constructions by default.
- US certification schemes will issue certifications based on US guidelines. Whilst products might support hybrid constructions, US certifications will probably mandate non-hybrid constructions by default.
- The Dutch audit office has expressed concern that PQ migration is not happening fast enough [2]
- Manufacturers are helped by standards such as IETF RFCs to develop against. We need manufacturers to make products and they need markets to sell to. It is not easy to take a proof of concept and make a commercially supported product and put it through an evaluation process.
- During an evaluation process it is not only the cryptographic algorithm that needs to be considered, the size and complexity of the underlying source code can play a role in how smoothly an evaluation processes. It is not unreasonable to argue that a smaller code base is easier to evaluate (non hybrid). There might well be an argument to be made that post Q date, hybrids don't offer redundancy in the implementation if a security function fails.
-----Original Message-----
From: Joseph Salowey via Datatracker <[email protected]>
Sent: 24 June 2026 16:00
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]
From: Joseph Salowey via Datatracker <[email protected]>
Sent: 24 June 2026 16:00
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]
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
