[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Henrick Hellström]

Hi Bas,

That is my point.



On 2026-07-04 17:47, Bas Westerbaan wrote:

There are some known security issues with some ML-KEM implementations, but no known security issues with ML-KEM that are of immediate relevance to the way it is used in TLS. I honestly don't understand the opposition to this draft. I can understand why it is marked as N (not recommended) in the IANA registry, but not why there can't be an informational RFC that specifies the way it is supposed to be implemented, if or when it is supported by a conformant interoperable TLS implementation.

Hi Henrick,



Best,

  Bas

Would you mind explaining how an attacker would use a timing side- channel attack against ephemeral use of ML-KEM in TLS? On Sat, Jul 4, 2026 at 4:53 PM Henrick Hellström <henr...@streamsec.se <mailto:henr...@streamsec.se>> wrote:

    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.
    _______________________________________________
    TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org>
    To unsubscribe send an email to tls-le...@ietf.org <mailto:tls-
    le...@ietf.org>

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org