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 AFA8CBFE98A4 for ; Fri, 27 Feb 2026 13:05:48 -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 olmPgCK5Aojx for ; Fri, 27 Feb 2026 13:05:46 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 328A9BFE9832 for ; Fri, 27 Feb 2026 13:05:34 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-896fcfc591eso23607706d6.2 for ; Fri, 27 Feb 2026 13:05:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772226334; cv=none; d=google.com; s=arc-20240605; b=WTh7Mqd/lSwj0D4Rs1sLBmA8d9dWSjNymLV27S8KO27S7Zs2FuWIyFCAR82yg7OTWg 8zM4cZ7oFhSIqfb+E3DRZiCy4rwx3jTBGGYPmwbjJ0KxAm5kxIi8/srYEC3mdxRubi5w /u549SzmkS71qFHFojgN+M5Mn2CMDX1oxaY3VlFJi6/DLAAfDMB2B1rqYSvM4iMFTmFJ iqB7daXNPW986tGesXeIN9Q3UFBL4DX3rZQ4XzVxbiErDXJcUdcXLMDvdhBIuvFJNlq2 SNQIQp3LmMpJhnqjyAsd3E3KeFaIwqtJcRw4ESGqw3WKvs6MAvZZq73FWaNyuUy7gKal kwIQ== 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=bHCPKICkC21jUvFNIvNRxfUSJmNJ/aBQCSzQ4wR4XoU=; fh=esLjNc+Q9MNEverTF7oKbS+QMWsl/hBlOHBVOHKSvd8=; b=EX/iNDBtf9y6RWonQdkenx1DAdJrWzCYHXVvO+h9jLBTp8YYo5IPwdb5fvSioWVPxf DmRhkYUjjkwO1CBFwnJyBtR6koLKMCN6wuVlbkTrZxRqLNpROUsxehdjoQ0SyRZZJjBS 0sLxw5qhciKttUgiWqg0ER3E5Tl4aJMH1A7GCaq6ewZA5nBFHX0KpkBBpxHERFewC51n P0Mapg27QlA3AWKNzXEvhhJRG1CI5IDF6rL5id1V9CLmJvDXjmD6YoKk5PzGQkD63b+j ACEEsPuMxWdUToLQX8BWIZyQSDifXaUZ+b2rYQu3SkzXsmbrHEk71vYv3YHjH8yH+WOz zInw==; 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=1772226334; x=1772831134; 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=bHCPKICkC21jUvFNIvNRxfUSJmNJ/aBQCSzQ4wR4XoU=; b=dHhX//Lhyl8ieQyFg7GaCWq2UttjTzHZNDHxHPv1CRO9n3KGgAglxrclTsplUVxCGm CpC0AgTjBU2y6aKUMciWoySrUexwW1YAo4UkR2QtT+p9Xtr5Ctp/tt0tKUdNBmOJC5fQ dLRhNOQxkcU7HDJIaCr6o2UsggZDghtKfZoIE1Pm8CnOb7BTCyly05eX1JWmh/4hXVA0 US3M5m6SY7I00lse3I5ewbWCG3Rwbig1gSbWuIa7B7NOxtBlYpsyQHroVTzvJ4w6/qUH hnPMtv20jnFpWDXWL0bP/pAZWxJepWaAKn6aLTKFoH5w8Ms729y5kcVQPzmeaZGSotPY 4D5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772226334; x=1772831134; 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=bHCPKICkC21jUvFNIvNRxfUSJmNJ/aBQCSzQ4wR4XoU=; b=jLMuZczcl/GyzPLeYpbcC5cQmy2CbPPPy/Wyenq6hHCnXtNNcvh2YxnsnLzCJeTVrH DUNj5zGPIz/nI1NlafpvgFoQoJDHfPqXmVD2v+yVElYl6d+oIwIMBdDbtr3yIMWfgJdO szBiTD14XbTrmMOyadNK9Vdr0WxZqvoecRGQogIow6XsPzt10cON3gm3yjcZD6jGIf/F +qW15GGg7dxoI+SYKwFrTkupudTr4ZoQA/D3D11t/A0lHH9xiPwM+a6yLKgGfzHMyH/2 0Zzd4fL5UrHkI59ADtBCotHI1ieLbKroVgiSKjwXe9IvrzJsNbAKCnBew0N2ert3Tgei ltwA== X-Gm-Message-State: AOJu0YzVJvxzMeU8pK0T2kIwCHWea7rJ7Oni/7ZLNsGDplZST3kohn42 vniSW99cvMvaf7Qa0l/s1kQvux4n6+bwlvX0Za7vzbOxsPYhRgG3sH9pqq7AKZsl19SOTPggvuC 1dIvRAm7/euxa53D2Z9hOeOyIexkJj2ozEx5gz44= X-Gm-Gg: ATEYQzwAhDfOkbWJn40N4Q6JXVcmvUM7Cjl1sF0Ahmvy/y7NLLxAVNZC9qL0upxckFl oltW4+uXv3BxwyHe6oDbcZxGxQTDeM/Elfur6yTIMuR87+qkYLLjaMh7V3XwGd6gc3e+mq396lK ohnzN43xsby2kJAqoCoCfmo6EPyxBYGCLa0gmfsxtKSmJO/eymcyBaxSH5O3vQVmRhxBXp+kDVY a4EnuupDkZNh2zl8bAqDV//D2UNNu69e/w7rpLUepvSCStEOl5gGOHK+3NRD/XwDOsGJ/w74zt9 sOkv71sofQ== X-Received: by 2002:a05:6214:c22:b0:896:fbdd:ef1d with SMTP id 6a1803df08f44-899d1d862f0mr65314106d6.3.1772226333422; Fri, 27 Feb 2026 13:05:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Deirdre Connolly Date: Fri, 27 Feb 2026 21:05:19 +0000 X-Gm-Features: AaiRm53QvYbJGmWPkfwDGjBO3nD40pKBbd3T0k-3vhSTbufOnk5361Ym7ianZQU Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary="00000000000010b8ce064bd49925" Message-ID-Hash: MLZYZI3LXY6SNZNXFN6FIWTU7ACETKND X-Message-ID-Hash: MLZYZI3LXY6SNZNXFN6FIWTU7ACETKND 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: --00000000000010b8ce064bd49925 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Also, the text recommending not reusing keys could use RFC 2119 keywords= . Only -bis updates to 8446 can change normative requirements here. This was already discussed and resolved for earlier documents (I'm pretty sure it was regarding -hybrid). The latest 8446bis draft ( https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html) says "Clients and Servers SHOULD NOT reuse a key share for multiple connections" and that will flow down to hybrid kex and non-hybrid kex equally. On Fri, Feb 27, 2026, 8:17=E2=80=AFPM Ilari Liusvaara wrote: > On Thu, Feb 12, 2026 at 11:05:22AM -0800, 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 > > < > https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-tls-mlkem-05&url2= =3Ddraft-ietf-tls-mlkem-06&difftype=3D--html > > > > > > > > The main focus of this WGLC is to review new text providing more contex= t > > around the use of pure ML-KEM. For those who indicated they wanted thi= s > > text, please let us know if the new text satisfies you and if you suppo= rt > > publication. This working group last call will end on February 27, 2026= . > > Some comments: > > - The document could expand on impact of key reuse. Known impacts > include: > > * Linking connections from the same client, which may be a privacy > risk. > * Making exploiting side channel attacks and implementation flaws > much easier. > > Also, the text recommending not reusing keys could use RFC 2119 > keywords. > > > - Also the document could expand on applicability. Known use cases > include: > > * ML-KEM-512: Constrained systems that nevertheless require security > against quantum adversaries. ML-KEM-512 is among the most efficient > quantum-resistant key exchanges known (at least among the not-too- > exciting ones). > * ML-KEM-1024: Protecting classified data (up to TOP SECRET level) in > United States. ML-KEM-1024 is the only key exchange in the CNSA2 > profile. > > > And some notes, mainly on why I disagree with comments that this draft > should not be published: > > > - There does not seem to be any evidence that ML-KEM is weak. I think > that if ML-KEM gets badly broken, it will be for unforeseeable reasons > (which is a risk for any cryptographic algorithm, including prime- > field ECC). > > This is in contrast to things like RC4, where evidence that it is > bad did exist at the time TLS 1.0 was developed. > > Futhermore, I regard the inclusion of ML-KEM-1024 in CNSA2 as a > serious endorsement. > > I personally think that using hybrids for encryption is worth it, but > it is close a call, and I can see that even relatively small weight > differences may tip the scale the other way. > > > - I do not think ML-DSA FO design is bad. While possibly not optimal, > I think it is very decent. I do not think passing raw entropy is > significant problem, as it seems to matter only with backdoored RNG, > which is something the extra hash in Kyber can not defend against. > > In short, I think the differences between Kyber and ML-KEM are > improvements. > > > - There are already 6 references on the construction, and I did try > giving it some good blows myself, obviously that did nothing to > stand-alone ML-KEM. > > > So I support publication. > > > > > -Ilari > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org > --00000000000010b8ce064bd49925 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Also, the text recommending not reusing keys could u= se RFC 2119=C2=A0 keywords.

On= ly -bis updates to 8446 can change normative requirements here. This was al= ready discussed and resolved for earlier documents (I'm pretty sure it = was regarding -hybrid). The latest 8446bis draft (https://www.ietf.org/a= rchive/id/draft-ietf-tls-rfc8446bis-14.html) says "Clients and Ser= vers SHOULD NOT reuse a key share for multiple connections" and that w= ill flow down to hybrid kex and non-hybrid kex equally.

On Fri, Feb 27, 2026, 8:17=E2=80=AFPM Ilari Liusvaara <ilariliusvaara@welho.com> wrote= :
On Thu, Feb 12, 2026 at 11:05:22A= M -0800, 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/d= oc/draft-ietf-tls-mlkem/
>
> The diff with the previous WGLC draft (-05) is here:
>
>
> https://author-tools.ietf.org/iddif= f?url1=3Ddraft-ietf-tls-mlkem-05&url2=3Ddraft-ietf-tls-mlkem-07&dif= ftype=3D--html
> <https://author-tools.ietf.org/= iddiff?url1=3Ddraft-ietf-tls-mlkem-05&url2=3Ddraft-ietf-tls-mlkem-06&am= p;difftype=3D--html>
>
>
> The main focus of this WGLC is to review new text providing more conte= xt
> around the use of pure ML-KEM.=C2=A0 For those who indicated they want= ed this
> text, please let us know if the new text satisfies you and if you supp= ort
> publication. This working group last call will end on February 27, 202= 6.

Some comments:

- The document could expand on impact of key reuse. Known impacts
=C2=A0 include:

=C2=A0 * Linking connections from the same client, which may be a privacy =C2=A0 =C2=A0 risk.
=C2=A0 * Making exploiting side channel attacks and implementation flaws =C2=A0 =C2=A0 much easier.

=C2=A0 Also, the text recommending not reusing keys could use RFC 2119
=C2=A0 keywords.


- Also the document could expand on applicability. Known use cases
=C2=A0 include:

=C2=A0 * ML-KEM-512: Constrained systems that nevertheless require security=
=C2=A0 =C2=A0 against quantum adversaries. ML-KEM-512 is among the most eff= icient
=C2=A0 =C2=A0 quantum-resistant key exchanges known (at least among the not= -too-
=C2=A0 =C2=A0 exciting ones).
=C2=A0 * ML-KEM-1024: Protecting classified data (up to TOP SECRET level) i= n
=C2=A0 =C2=A0 United States. ML-KEM-1024 is the only key exchange in the CN= SA2
=C2=A0 =C2=A0 profile.


And some notes, mainly on why I disagree with comments that this draft
should not be published:


- There does not seem to be any evidence that ML-KEM is weak. I think
=C2=A0 that if ML-KEM gets badly broken, it will be for unforeseeable reaso= ns
=C2=A0 (which is a risk for any cryptographic algorithm, including prime- =C2=A0 field ECC).

=C2=A0 This is in contrast to things like RC4, where evidence that it is =C2=A0 bad did exist at the time TLS 1.0 was developed.

=C2=A0 Futhermore, I regard the inclusion of ML-KEM-1024 in CNSA2 as a
=C2=A0 serious endorsement.

=C2=A0 I personally think that using hybrids for encryption is worth it, bu= t
=C2=A0 it is close a call, and I can see that even relatively small weight<= br> =C2=A0 differences may tip the scale the other way.


- I do not think ML-DSA FO design is bad. While possibly not optimal,
=C2=A0 I think it is very decent. I do not think passing raw entropy is
=C2=A0 significant problem, as it seems to matter only with backdoored RNG,=
=C2=A0 which is something the extra hash in Kyber can not defend against.
=C2=A0 In short, I think the differences between Kyber and ML-KEM are
=C2=A0 improvements.


- There are already 6 references on the construction, and I did try
=C2=A0 giving it some good blows myself, obviously that did nothing to
=C2=A0 stand-alone ML-KEM.


So I support publication.




-Ilari

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