IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

Jack Grigg <ietf@jackgrigg.com> Tue, 24 February 2026 02:16 UTC

Return-Path: <me@jackgrigg.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 389ABBCB4A7D for <tls@mail2.ietf.org>; Mon, 23 Feb 2026 18:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eruh0cXTACF1 for <tls@mail2.ietf.org>; Mon, 23 Feb 2026 18:16:10 -0800 (PST)
Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6049ABCB4A64 for <tls@ietf.org>; Mon, 23 Feb 2026 18:16:10 -0800 (PST)
Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so879196666b.2 for <tls@ietf.org>; Mon, 23 Feb 2026 18:16:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1771899363; cv=none; d=google.com; s=arc-20240605; b=Zs59zTz7iPWYiYRK2rAaT7PijVj+DAx72cl4uF4C95Yhzwn39zfTYiOuiTpsWN+dbk FDyBkUiyvaDlhLA7DIJlz/1/83c9NzJHBugCb0GPDDXGFXj02lwZMu1lCvwM9gbxlLpf jI2zVTU3O+Jr+z2avkMfNJjo8VxFoOdJzY/iIO82n/3M2ph4vd3UDmowAo7je6xla4H2 yezezhv0MNaCNLgYCk3Aei+DqBRmgehbRFE2dHX6NtHhuU1SdcLY8uoYd83GTCoDgH3a 6X1PLK3PDeYxN3Abfz9Bo3Zu/UVCp5WL0cRF7P+9FiBBiCudY1rurrNmvR+Dqs+4JjU3 2Smw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version; bh=nfoRtEUXnk+MP0C+u5O+5A6Yo9qZIDuoTEa3fqGgVlY=; fh=6dNaabedNczh5TXKCP3vnXRLFdmtidwzU4uB2XwvFYI=; b=E7pnA8vC2jDAJ3hIiqeBB8g9HgcB0Q5XxxaUnPWslgj2KJnSYlmcPGcU6G3xVrOcN7 L1UgmUPvkKgtoYZuxeOHoQb2Snl9IFLPt03xrT+fTxWrue/EzEsEDC3yKNnqrFuSJlT9 d2tjLFJW5qDqoR6DhIgwS9gdivCLOpmZ9FLXZUVx7C2nHWCsXj62axLHQeJRvo7t9cWq dI5KNaMRzswy7hjyETQbEK/Ineu7mNlho4vFDy+Wzh1LkJMXKcHswY2tEBMQ395qcerf J1yjGLq5VcGbUgREREBdQiRLnkroQq6u0OzfvrMe5eObs+84zEDoGefM7lxxdJG5xBHL +hJA==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771899363; x=1772504163; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nfoRtEUXnk+MP0C+u5O+5A6Yo9qZIDuoTEa3fqGgVlY=; b=gAtFGozNKgn9Xpqx3M2UTYFP0RBKtQ8sDinrQMZUv67bi6byHgNUUjd7rI+358rXlq /UvlmSdnPwZv3gmmStpFPn8HFNWbzOIvoOeUTwypd6S5Nw01fO7Z/QYgJ5ti3TLfIv7H VeJQvizPVdxBtyh0GZMLzYILImW9Bxc0y22axRBrQd/dbDSOlgWE725rOOBoA7LQRey1 OrBdVSSOqel3bhmamnIs+rXIE0GcJXP7+dgCI39DTQ2yZiCzEDavX/yyijdNFum6oAoJ Z5D1ge3DarI3JEgZsWPtOBIcIAX8pwdcxbdRjfO4E4EKoC7hY15mexZu8i8RvylfM16O 8hNA==
X-Gm-Message-State: AOJu0Yw4OaAai9Xii23Ra3EFFmKZIyZIrEy78GEqfUboRYSaGCSFoENL cNBaGItA0amr224iydxG8Ex+6NaxihmHpKM+rEbMQ+AxGtdk/0E16SvxyjEy6wWtpUtaYm9XuEI dE0x4SRIErL5HUM1tiM8MKcjOtW9jpWuKxhQ+v8A/XxrTo3hyf2IF3SOwVQ==
X-Gm-Gg: AZuq6aLO0WjLbEs/80CaTdRWyXi7WQtJf6y64KJtJJ4E1FyrG/d4qnOMq0HdWbh75iy CkaASkJdP+J9hhorKgKWt4/p74ZVzO6T+yHarrRA7a2cN4jIGCEp0eMqa3NX8Fl1HJZJU0MZe6N /SAKNM0F6pdAuxS28xawCidfpI/8nWWMmaXw2Q30rKG875KG8YCfnFT4lDCJES1Ls5ZNmy4Ed6l 5h3byaeqHo+mNVhkXmG9PJBhwmxbVjSxYW/4T6qbA385VS0lz20gaVj9rgym8FHFFqB3snJ/l0S E5zYGPE=
X-Received: by 2002:a17:907:1c18:b0:b87:d09c:1825 with SMTP id a640c23a62f3a-b90819b3000mr648965866b.13.1771899362650; Mon, 23 Feb 2026 18:16:02 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com> <CABcZeBM6sHJArV1FuWYbRA=XJtQiKKbmAeYt0YJuy4zAU2Ak7Q@mail.gmail.com> <CAFR824z6u9eCqk2UwXU=GCmq8i95ue3P-DLSfj97cEa8bXU6EQ@mail.gmail.com>
In-Reply-To: <CAFR824z6u9eCqk2UwXU=GCmq8i95ue3P-DLSfj97cEa8bXU6EQ@mail.gmail.com>
From: Jack Grigg <ietf@jackgrigg.com>
Date: Tue, 24 Feb 2026 15:15:51 +1300
X-Gm-Features: AaiRm50oqxoBWouGexODwcPo_OGb5qqIU2w7uOWthmSnBT_tWs9ZPgEAWkj6L4I
Message-ID: <CAPC=aNUdV2FbTAAsMQ2LHtuKAP0RLi=EC6TubvWWt6u90OxprQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000016b987064b88785e"
Message-ID-Hash: EBWR677HI6VG3X7P4TGYU5WOIBFREJV7
X-Message-ID-Hash: EBWR677HI6VG3X7P4TGYU5WOIBFREJV7
X-MailFrom: me@jackgrigg.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: ietf@jackgrigg.com
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DY1Iy3g5YdXcvcuBpskMcqLtmFo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

I have now reviewed the current state of the document [0], as well as the
diff originally proposed for this WGLC [1] and the subsequent diff
resulting from WGLC discussion [2].

I support the publication of this draft.

Cheers,
Jack

[0]
https://github.com/tlswg/draft-ietf-tls-mlkem/blob/237c19cb3a795e6c7de54b7e71f3366d66c2f510/draft-ietf-tls-mlkem.md
[1]
https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html
[2]
https://github.com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-07...237c19cb3a795e6c7de54b7e71f3366d66c2f510

On Tue, Feb 24, 2026 at 2:40 PM Deirdre Connolly <durumcrustulum@gmail.com>
wrote:

> I've pushed basically all of these changes up to github, as well as adding
> citations for much of the pertinent work on analyzing KEMs in TLS key
> agreement in multiple security models etc
>
>
> https://github.com/tlswg/draft-ietf-tls-mlkem/blob/main/draft-ietf-tls-mlkem.md
>
> On Sat, Feb 21, 2026 at 5:52 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>> I am mostly indifferent to whether this document is eventually published,
>> though sad that we're spending so much time debating it in the WG,
>> given the relatively minimal practical effect of publication.
>> Specifically:
>>
>> - The code points have already been registered
>> - This document is to be published as Innformational with Recommended=N.
>>
>> It's not clear to me that the publication or non-publication of this
>> document will have much of an impact either way on the deployment of
>> this mechanism.
>>
>>
>> With that said, I believe that the current document has some issues
>> which need to be addressed if it is to be published
>>
>> S 1.1.
>>
>>    FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum
>>    [RFC9794] key establishment via a lattice-based key encapsulation
>>    mechanism (KEM).  This document defines key establishment options for
>>    TLS 1.3 that use solely post-quantum algorithms, without a hybrid
>>    construction that also includes a traditional cryptographic
>>    algorithm.  Use cases include regulatory frameworks that require
>>    standalone post-quantum key establishment, constrained environments
>>    where smaller key sizes or less computation are needed, and
>>    deployments where legacy middleboxes reject larger hybrid key shares.
>>
>> I don't think this middlebox text is really on point.
>>
>> If we look at John Schauman's helpful breakdown of a hybrid CH that
>> offers both X25519 and X25519/Kyber768, we see that the total CH is
>> 1815 octets. Swapping out the hybrid for MLKEM-768 would buy you 23
>> octets, which doesn't change things materially. If we were to swap to
>> MLKEM-512, this would buy us another 384 octets, so assuming I'm doing
>> the math right, just that change gets us down to 1431 bytes, so it's
>> *just* possible that this might be large enough to push you into two
>> packets in some cases where the rest of the CH was appropriately
>> sized. I'm skeptical that this is going to be very frequent,
>> especially in light of the fact that at least the CNSA profile 2.0 [0]
>> requires ML-KEM 1024, which has a 1568 byte key, thus putting us
>> squarely in the zone of two packets with or without a hybrid.
>>
>>
>>
>>
>> [0]
>> https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-02.html
>>
>>
>> S 4.2.
>> As a number of people have observed, much of this text repeats text in
>> 8446 and contradicts the negotiation algorithm there, which depends on
>> the group list, not the key shares. You should remove everything up to the
>> graf that starts "For the client's share".
>>
>>
>> S 4.3.
>> Here too, the diagram seems duplicative, so I would remove it.
>>
>>    The shared secret output from the ML-KEM Encaps and Decaps algorithms
>>    over the appropriate keypair and ciphertext results in the same
>>    shared secret shared_secret as its honest peer, which is inserted
>>    into the TLS 1.3 key schedule in place of the (EC)DHE shared secret,
>>    as shown in Figure 1.
>>
>> I don't know what "honest" is doing here. If you connect to a malicious
>> peer, you might still get a shared secret.
>>
>>
>> S 5.2.
>>
>>    While it is recommended that implementations avoid reuse of ML-KEM
>>    keypairs to ensure forward secrecy, implementations that do reuse
>>    MUST ensure that the number of reuses abides by bounds in [FIPS203]
>>    or subsequent security analyses of ML-KEM.
>>
>>    Implementations MUST NOT reuse randomness in the generation of ML-KEM
>>    ciphertexts.
>>
>> This kind of normative language doesn't belong in Security
>> Considerations.  If it's important it should go elsewhere.
>>
>> -Ekr
>>
>>
>>
>> [0] https://www.netmeister.org/blog/images/kyber-kex-wireshark-ch.png
>>
>> On Thu, Feb 12, 2026 at 11:06 AM Joseph Salowey <joe@salowey.net> wrote:
>>
>>> This message starts the second Working Group Last Call for the pure
>>> ML-KEM document (draft-ietf-tls-mlkem-07).
>>>
>>>
>>> The file can be retrieved from:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
>>>
>>> The diff with the previous WGLC draft (-05) is here:
>>>
>>>
>>>
>>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html
>>> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html>
>>>
>>>
>>> The main focus of this WGLC is to review new text providing more context
>>> around the use of pure ML-KEM.  For those who indicated they wanted
>>> this text, please let us know if the new text satisfies you and if you
>>> support publication. This working group last call will end on February 27,
>>> 2026.
>>>
>>>
>>> Thank You.
>>> _______________________________________________
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-leave@ietf.org
>>>
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-leave@ietf.org
>>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

v2.40.1 | Report a Bug | By Email | System Status