IETF Logo Mail Archive

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

David Adrian <davadria@umich.edu> Thu, 12 February 2026 20:15 UTC

Return-Path: <davadria@umich.edu>
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 5E475B67B6DE for <tls@mail2.ietf.org>; Thu, 12 Feb 2026 12:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 j8Fn67H5WpSu for <tls@mail2.ietf.org>; Thu, 12 Feb 2026 12:15:45 -0800 (PST)
Received: from ghoul.relay-egress.a.mail.umich.edu (ghoul.relay-egress.a.mail.umich.edu [18.217.159.240]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4AB32B67B697 for <tls@ietf.org>; Thu, 12 Feb 2026 12:15:44 -0800 (PST)
Received: from punctual-ellyllon.authn-relay.a.mail.umich.edu (ip-10-0-72-145.us-east-2.compute.internal [10.0.72.145]) by ghoul.relay-egress.a.mail.umich.edu with ESMTPS id 698E34E9.340B50FA.172EAA9B.758703; Thu, 12 Feb 2026 15:15:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-0; t=1770927337; bh=CEMw7Xvx8QuTSJydq1XmO3jo2CW8/klZxaOiB+trLAY=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Cx/s9mRnrilklwi4arzGRTyLHwo2OlZaCv28Ld6ZA9mgDCUuv9dHddeKUpim9e0Y6 9uipgVPnnLJqSjPN876/RxqGv47JHc4MtPMa5SfNSkyC19SytPrAwCbTEGFeqEtNNb lM4fCdF44VH058dhBCCtnmjybqvRP0nPz9TwOOYIPndu+zoZ24r4+2kwsciQL6Vek2 r1mc7oD5m+rfyN0desXNjq87JTl2Dhi3mIi29rj8hdobO8lmjSL1O9RBBYx/Z8o2Y1 MXxGYxKvolyTN/1A6c6z3oXQ99jkCGLWqF4MNNTizBKEBWAQ7Va4rS+221FiVjLQKf WPXAsjLVqLPRQ==
Authentication-Results: punctual-ellyllon.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.167.43 (mail-lf1-f43.google.com); auth=pass smtp.auth=davadria
Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by punctual-ellyllon.authn-relay.a.mail.umich.edu with ESMTPSA id 698E34E9.6924476.5E5FF6F.3245588; Thu, 12 Feb 2026 15:15:37 -0500
Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-59dd54b1073so227565e87.0 for <tls@ietf.org>; Thu, 12 Feb 2026 12:15:36 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCXxT+qt3ZEGCPWT3/s4M8OBtRzaOsVhkfJkROtx/+FV9+U5R4vfgH5NpS7JcG+YSxqlyfY=@ietf.org
X-Gm-Message-State: AOJu0YwzjsVbMtIh+ykLbxivMda3QuOaTOG37oFsh7w954PgHfPyUpKV xQ7xzLu5FeS+swixFRw32UaQ6Nkv0AkKPV/Ozo1z0OpftBg/THJheuV9wmVWCKtTO6Wd360Ef9t N1YJG0G1jyxa5BhD3yPlLoBCb5118cxM=
X-Received: by 2002:ac2:568c:0:b0:59e:4586:24e7 with SMTP id 2adb3069b0e04-59eec190d01mr77046e87.18.1770927335173; Thu, 12 Feb 2026 12:15:35 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com> <AS5PR07MB10596FC9D182E975AA0E11F8E8960A@AS5PR07MB10596.eurprd07.prod.outlook.com>
In-Reply-To: <AS5PR07MB10596FC9D182E975AA0E11F8E8960A@AS5PR07MB10596.eurprd07.prod.outlook.com>
From: David Adrian <davadria@umich.edu>
Date: Thu, 12 Feb 2026 15:15:22 -0500
X-Gmail-Original-Message-ID: <CACf5n7_bH6w+jo4=CW2sQ87b5YUk1t+ngtCG+JH2YjpX9C8cMg@mail.gmail.com>
X-Gm-Features: AZwV_QgrjmjNEHmCGaj-HDL6NNUCQtmvmGqp-7oVGXQCS4j4WVrr_l8K0gKRSxs
Message-ID: <CACf5n7_bH6w+jo4=CW2sQ87b5YUk1t+ngtCG+JH2YjpX9C8cMg@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bc76c4064aa62649"
Message-ID-Hash: DLNFIW7EIITHQJ4EK2F37WSMWPYJIPPJ
X-Message-ID-Hash: DLNFIW7EIITHQJ4EK2F37WSMWPYJIPPJ
X-MailFrom: davadria@umich.edu
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: "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
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/xNscK_NN7farxzEo5BtJl8ncc80>
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 support the publication of this draft, and note that Chrome has
implemented ML-KEM 1024, currently requiring explicit configuration, and
that ML-KEM 1024 can be used to connect to certain Google properties.

I find the remaining word smithing to be at best, a waste of time, and at
worst, potentially inaccurate.

I recommend the document be published as-is.

On Thu, Feb 12, 2026 at 3:10 PM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
> I support publication iff all text related to “key reuse” is removed. In
> its current form, I do not believe -07 should be published.
>
> Major Comments:
>
> - FIPS 203 states that:
>
> “the licensed patents be freely available to be practiced by any
> implementer of the ML-KEM algorithm as published by NIST.”
>
> “requirements for the secure use of KEMs in applications, see SP 800-227.”
>
> A reused key is, by definition, a static key. SP 800-227 imposes
> additional requirements for static keys compared to ephemeral keys. The
> draft does not explain how an implementer can satisfy these requirements.
> This creates potential non-conformance with NIST specifications.
>
> -  The draft does not describe the significant security and privacy
> problems associated with key reuse. IND-CCA is a theoretical property of
> the algorithm. However, the security and privacy problems are related to
> the reuse of keys in the TLS 1.3 protocol in deployments.
>
> Minor Comments:
>
> - The discussion of randomness reuse in ciphertexts and references to SP
> 800-227 do not belong in a “key reuse” section. Ciphertexts are not keys,
> and SP 800-227 contains broader guidelines and requirements beyond static
> keys.
>
> - “The client's shares are listed in descending order of client
> preference; the server selects one algorithm and sends its corresponding
> share.”
>
> The server may also select no share and respond with a handshake_failure
> or a HelloRetryRequest (HRR). Since this is already specified in RFC 8446,
> it would be better to remove this text and simply reference RFC 8446.
>
> - Section 5.1 appears to ​mix different concepts: hybrids, PQ/T hybrids,
> and lattice-based PQ/T hybrids. I assume the person asking for this section
> wanted a comparison with [ECDHE-MLKEM]. I suggest doing that. In the
> future, PQ/T hybrids will likely become less common, but it is unclear
> whether other hybrids (e.g., ML-KEM + HQC-KEM) will gain adoption.
>
> Cheers,
> John
>
> *From: *Joseph Salowey <joe@salowey.net>
> *Date: *Thursday, 12 February 2026 at 20:06
> *To: *
> <tls@ietf.org>
> *Subject: *[TLS] WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
>
> 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
>

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