I have followed the discussion on this topic and support publication of this document as a RFC.

Short motivation: Recognizing the there might be a high risk of implementation bugs or timing issues with new implementations, is a terrible reason to delay the publication of an informational documentation of a mechanism that is given status N (not recommended) in the IANA registry.

Henrick Wibell Hellström
StreamSec

On 2026-06-24 17:00, Joseph Salowey via Datatracker wrote:
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to