Return-Path: 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 37EBEBB6D870 for ; Sat, 21 Feb 2026 14:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KcWnFMtxJx9p for ; Sat, 21 Feb 2026 14:59:26 -0800 (PST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 5EB57BB6D866 for ; Sat, 21 Feb 2026 14:59:26 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-8966bd9da41so32547946d6.2 for ; Sat, 21 Feb 2026 14:59:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771714766; cv=none; d=google.com; s=arc-20240605; b=TCZNyzwxGNcqqDgQENzmXbzkZw4HP6dFLIp8WAkQUgUsFuwGo7lpiEnB/oB4PGKMxC bQlPmypFxfpSp82EcBbSRfZsPupc9miuegKRKcK8R5Y5pSACfRsC5ne4JgsdA/JHaUOl kP929CmzlHbJgU7Esn1zJe+8PdA4VAu/g0jtcSn3Qn46ql5+dnZLslkd0MzRCP+fPcXl FmeASbjKTnMVzYjH5pcSXyiQ1auUeQg2QFR2n/Yh1RqSBW6RYad4uoxgdBSgqP8JAAmV jeolQAT+nTd6KqQo6/3S7xtJnQO28Nbo5lwI8oPUzJgADv8nzChV54r1dpiwMWb6QK1a Mb0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=cOZ3Y4Rw88CjY2goByg1iPb3guboDgPrknIygT/WpOc=; fh=wof8ZCxAfJWFkQ2unu18qFNgyvhaKAwezSLVlGPI51U=; b=O5A/6pZIk9P/V8l7aHG+5pPS/EOjXlBrgfx+m3wBAcKjMcjEB4kXMq1nFiEt3UsZm9 mYDsJbcbdHEqYRn9mBLQQxYsjrpcRK5Gz1mRicN8/eHsW/85JOtDCWT9iFiaerRVuX4Z oaP9QP/JtG2Fcf3T/nAxLYTek2M0+pq4nFVw5dldhmuFPG/ZKYsgHHW3df5pbNIKN6qD y3uu/E6Mwa3RwicuJGGUOh++m0gKsSIXYwtCJzWSIn3F66v9YS7hDbg/vQba53yufEpp extSBiQOlEjxM+A8knIfpIDDwy/7YsxjeT6p9eGepjGhE/+vVCcnc0/ehyrJdNoE3Dan r9Hw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771714766; x=1772319566; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cOZ3Y4Rw88CjY2goByg1iPb3guboDgPrknIygT/WpOc=; b=Cx2aeHc0SgWtOPzT9gtQ3qlWMfWrUBF1UgWZ0slmALZQ9rZvSE6EKPU522IIa1ZYMg 5XUpJcCLWS/MgpLcEWQibPxawSuTJdIS2DexyeTQlDENMBmiydHrKuL5QvjhOBwUicl4 aKJyf6sAZNn6SmgNIhyNumNfiS7AvxO3gt17H3UCqaH10I11hqt6dk0D8WOrhDrwoRVl ukyBhy+VkBvI/hEssBGaHoYpZpK6ufbBMFAc+ygkXaW0RPVxZxHfooAQthnguqo/K1tV piefKYUC5xqeG6eYKUFSPCCgzJiDAUlDF6dB8P3pQicB/SHHDRkyJqS03IsOgsUO9xvN rU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771714766; x=1772319566; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cOZ3Y4Rw88CjY2goByg1iPb3guboDgPrknIygT/WpOc=; b=B+ASK1O5laWB/zNO6N/ZfrGKdjaHGXNF0724kd1SWO+ns6bD7eBsU+L3YBhGblEcio QYRWVDLPLAq33R3ikFv2BgTdF/Epv/BO6rlJxw8Z4BUkzAc+AGk4vvOcYch9FjBE9iWI COvDlo0BdxpFe5KSBKYgYXK6nBpW+6/0XgHoHVi4+J909b4alEvbW4Fs4NeRSzHV+IoH Y8bEsNeKRZ7fVRH2Y8EX7DQV6LIaNqUkpboSu1ZhYmuRFHpOO76Xnz2OD65N0kDqzx9j UiLdykIZAuEk9SvCS5BL+HZnsn+IQk3czAfEGPOdou/n6O+vX1uk8qLk3kFB4JtURfR7 J8+Q== X-Forwarded-Encrypted: i=1; AJvYcCWlEPdazVFrbAGOwAV1lWZAzPsUtxlLU+z8S1MuY4NYt12B1NXF08oOOQgaehsW7QCFM4Y=@ietf.org X-Gm-Message-State: AOJu0YwJplXTdzN90+f8Mr9xe5d+wB50q1EmkD5HUBlNv8QN8u+/+xaq cwE0/rmqrgefc1oLKYo+cdKTGw+oEf6C8Ef/IFWOzew2FlR70x4b0IAp9AU/ErKnzk0xQiErdXF 7Q5o2+9J9wiu5as5qGWo47/uyMsVsTPqYDA6C X-Gm-Gg: AZuq6aKaygsGyS2ToSuxM7+B9Ac/w9wkhNLb6+D2I0Q6y2M1zx6Uz/EEj6BbxU67GKQ RXQoGlp6cFe5vq9NAUDTmoxzvOLkJSqRQ3oQcJVVTECZqEHDNF1uwA417o08iktsgZffzK/TR6a Cl09BKqjGSomGMYC4HTU/t0zjWt4H6evhsESzpVP+4oTWQS/e2MgdeCYDcAUOBj20SWxDEGQz4x InvF/r8vBMLGiNeeAmsnZA7GbQBV0wPPuuv3Yd+425IlzWMi4iZjA/nwJfwBR2is/lsqQtD2vq8 vkAbjo1Z X-Received: by 2002:a05:6214:1245:b0:88e:6db7:f999 with SMTP id 6a1803df08f44-89979c561c9mr65960436d6.6.1771714765539; Sat, 21 Feb 2026 14:59:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Deirdre Connolly Date: Sat, 21 Feb 2026 17:59:15 -0500 X-Gm-Features: AaiRm52Aei6tRKM2tFWv67eENRVYaTmbbF5EhyCbxQuEW8wfNbTPacpPLS05_MU Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary="0000000000003e505e064b5d7da2" Message-ID-Hash: I32OVNPESSZ4MTPFMAB6SU5GJTNITDSF X-Message-ID-Hash: I32OVNPESSZ4MTPFMAB6SU5GJTNITDSF X-MailFrom: neried7@gmail.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 CC: "" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-05_=28Ends_20?= =?utf-8?q?26-02-27=29?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003e505e064b5d7da2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I don't think this middlebox text is really on point. That text has already been removed as of -07 On Sat, Feb 21, 2026, 5:52=E2=80=AFPM Eric Rescorla 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. Specificall= y: > > - The code points have already been registered > - This document is to be published as Innformational with Recommended=3DN= . > > 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.htm= l > > > 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 th= e > 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=E2=80=AFAM Joseph Salowey = 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=3Ddraft-ietf-tls-mlkem-05&url2= =3Ddraft-ietf-tls-mlkem-07&difftype=3D--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 suppor= t >> 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 > --0000000000003e505e064b5d7da2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0I don't think this middlebox text is really= on point.

That text has alrea= dy been removed as of -07

On Sat, Feb 21, 2026, = 5:52=E2=80=AFPM Eric Rescorla <ekr@rtfm.= com> wrote:

I am mostly indifferent to whether this document is eventually publish= ed,
though sad that we're spending so much time debating it in the W= G,
given the relatively minimal practical effect of publication. Specifi= cally:

- The code points have already been registered
- This docu= ment is to be published as Innformational with Recommended=3DN.

It&#= 39;s not clear to me that the publication or non-publication of this
doc= ument will have much of an impact either way on the deployment of
this m= echanism.

=C2=A0
With that said, I believe that the current docum= ent has some issues
which need to be addressed if it is to be published<= br>
S 1.1.

=C2=A0 =C2=A0FIPS 203 (ML-KEM) [FIPS203] is a FIPS sta= ndard for post-quantum
=C2=A0 =C2=A0[RFC9794] key establishment via a la= ttice-based key encapsulation
=C2=A0 =C2=A0mechanism (KEM).=C2=A0 This d= ocument defines key establishment options for
=C2=A0 =C2=A0TLS 1.3 that = use solely post-quantum algorithms, without a hybrid
=C2=A0 =C2=A0constr= uction that also includes a traditional cryptographic
=C2=A0 =C2=A0algor= ithm.=C2=A0 Use cases include regulatory frameworks that require
=C2=A0 = =C2=A0standalone post-quantum key establishment, constrained environments=C2=A0 =C2=A0where smaller key sizes or less computation are needed, and<= br>=C2=A0 =C2=A0deployments where legacy middleboxes reject larger hybrid k= ey 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 toMLKEM-512, this would buy us another 384 octets, so assuming I'm doin= g
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<= br>packets in some cases where the rest of the CH was appropriately
size= d. 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 zon= e 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 p= eople have observed, much of this text repeats text in
8446 and contradi= cts the negotiation algorithm there, which depends on
the group list, no= t the key shares. You should remove everything up to the
graf that start= s "For the client's share".


S 4.3.
Here too, th= e diagram seems duplicative, so I would remove it.

=C2=A0 =C2=A0The = shared secret output from the ML-KEM Encaps and Decaps algorithms
=C2=A0= =C2=A0over the appropriate keypair and ciphertext results in the same
= =C2=A0 =C2=A0shared secret shared_secret as its honest peer, which is inser= ted
=C2=A0 =C2=A0into the TLS 1.3 key schedule in place of the (EC)DHE s= hared secret,
=C2=A0 =C2=A0as shown in Figure 1.

I don't know= what "honest" is doing here. If you connect to a malicious
pe= er, you might still get a shared secret.


S 5.2.

=C2=A0 = =C2=A0While it is recommended that implementations avoid reuse of ML-KEM=C2=A0 =C2=A0keypairs to ensure forward secrecy, implementations that do r= euse
=C2=A0 =C2=A0MUST ensure that the number of reuses abides by bounds= in [FIPS203]
=C2=A0 =C2=A0or subsequent security analyses of ML-KEM.
=C2=A0 =C2=A0Implementations MUST NOT reuse randomness in the generati= on of ML-KEM
=C2=A0 =C2=A0ciphertexts.

This kind of normative lan= guage doesn't belong in Security
Considerations.=C2=A0 If it's i= mportant 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=E2=80=AFAM Joseph Sa= lowey <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 retrieve= d 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=3Ddraft-ietf-tls-mlkem-05&url= 2=3Ddraft-ietf-tls-mlkem-07&difftype=3D--html


The main focus of this W= GLC is to review new text providing more context around the use of pure ML-= KEM.=C2=A0 For those who indicated they wanted this text, plea= se 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.=C2=A0


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
--0000000000003e505e064b5d7da2--