IETF Logo Mail Archive

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

Benjamin Kaduk <bkaduk@akamai.com> Fri, 27 February 2026 21:54 UTC

Return-Path: <bkaduk@akamai.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 8A7AFBFF023B for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 13:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 g6-yiDszVlVe for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 13:54:25 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 E24FCBFF0236 for <tls@ietf.org>; Fri, 27 Feb 2026 13:54:24 -0800 (PST)
Received: from pps.filterd (m0409411.ppops.net [127.0.0.1]) by m0409411.ppops.net-00190b01. (8.18.1.11/8.18.1.11) with ESMTP id 61RLiuMr1633845; Fri, 27 Feb 2026 21:54:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=jan2016.eng; bh=FPyeq0Wx9OExUARk+dSj+auQHoulCjSdRulRERHcC3E=; b=cts6EJ4dn8MA 5h1L5gC3mv6Sn1htaGHuf0RF79dBx8X5vxoJQqgadQkt1Fn0nJMZ9nSl8ZlQvi4B L9TcjzmRP5CSsAE37PymKaNwlmgjHN60iyMpcZTOkKICVGTzHmFKnxYlaylku14K BxlEv3z97PngHkxA4t2xUMXZI5H4vpqnFsyo4xwpxk0UO+fo9cVxqu642aGn3HOE 0qMCHrQ3MsYHC7xEwUqXg9qLCEUp7pEQhKDxQno7exqV/37uS5/LYcpqJXpPwt25 Ya1p0Uor02LqqbpY/ahkqstzQKNqhROgSx/i1R3Z3BWa3PD2sLCKIcxY+ajuIjB2 hokPfhuwAg==
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0409411.ppops.net-00190b01. (PPS) with ESMTPS id 4cfpx680gm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Feb 2026 21:54:22 +0000 (GMT)
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.18.1.7/8.18.1.7) with ESMTP id 61RLn4fB022428; Fri, 27 Feb 2026 16:54:21 -0500
Received: from email.msg.corp.akamai.com ([172.27.50.220]) by prod-mail-ppoint8.akamai.com (PPS) with ESMTPS id 4ckb73u755-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Feb 2026 16:54:21 -0500 (EST)
Received: from ustx2ex-dag4mb7.msg.corp.akamai.com (172.27.50.206) by ustx2ex-dag5mb3.msg.corp.akamai.com (172.27.50.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Fri, 27 Feb 2026 13:54:21 -0800
Received: from ustx2ex-dag5mb4.msg.corp.akamai.com (172.27.50.221) by ustx2ex-dag4mb7.msg.corp.akamai.com (172.27.50.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Fri, 27 Feb 2026 13:54:21 -0800
Received: from akamai.com (172.27.164.43) by ustx2ex-dag5mb4.msg.corp.akamai.com (172.27.50.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29 via Frontend Transport; Fri, 27 Feb 2026 13:54:20 -0800
Date: Fri, 27 Feb 2026 13:54:17 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Joseph Salowey <joe@salowey.net>
Message-ID: <aaISiXnAwn2gxNF8@akamai.com>
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-27_04,2026-02-27_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2602130000 definitions=main-2602270193
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMjI3MDE5NCBTYWx0ZWRfX/RJO33uziNHO 5vBDd8cPTSeZ02+r8P9RgpjkXkAwR1pNaFv0+J4ZCVXbrr/LoQ4M/l3P8Xdva5Jj50QgwvTZ0Mx O2Zhv6AioALUfXGDpzs0qHr8pLy44ajAPs86b+bCmyoR8+xeQxgghWhbtFE2Wd2TF9FMg/BRqrM 7pVyZJihq5zk6LGwpn5kK50sSZyxNpkupMqUg78TsiNL+NYodTil/085sNIyeHzt9Lg9+cmy/pP UWeTHt4mEhIJr+UWGJ6IaXri/ywqEobKZvCYfJl2yOzgNts0wKnqIbO1Po/ZuvmwmccLgUipIjx 8xTUDIwjlIoThvyMNTRqMZYtgqLPRhb21B2LLIAmkCD578FbdY+Ja6sHquARV5WCr8C3Symvldl 0tOJSUUunsTBTY/eoHDTTvXKOoexDyN6IQU7nEwTGwyl3YF5MVuZ8O2QKsA/QszL13AfAdRxctB VJMtFoUvOeuseHg1Ymg==
X-Proofpoint-ORIG-GUID: C4iJOrTS7jXWEGZ0Nxb1K9DBlgdFBolb
X-Authority-Analysis: v=2.4 cv=Woom8Nfv c=1 sm=1 tr=0 ts=69a2128e cx=c_pps a=YfDTZII5gR69fLX6qI1EXA==:117 a=YfDTZII5gR69fLX6qI1EXA==:17 a=8nJEP1OIZ-IA:10 a=HzLeVaNsDn8A:10 a=VkNPw1HP01LnGYTKEx00:22 a=Ifg-1AOnLHOf1gn6spyb:22 a=XKgOefoLEnF0tNwW78TB:22 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=MCE-NAbwti0TSCF2qM4A:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10
X-Proofpoint-GUID: C4iJOrTS7jXWEGZ0Nxb1K9DBlgdFBolb
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-27_04,2026-02-27_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 spamscore=0 suspectscore=0 adultscore=0 priorityscore=1501 impostorscore=0 phishscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2602270194
Message-ID-Hash: 3P4ZJC3FLKFIMYTJYP2LBYIEXPFXH4RE
X-Message-ID-Hash: 3P4ZJC3FLKFIMYTJYP2LBYIEXPFXH4RE
X-MailFrom: bkaduk@akamai.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: "<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/H4gXrRF8gMTXSJAB2QtJO0MY2RA>
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>

On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote:
>    This Message Is From an Untrusted Sender
>    You have not previously corresponded with this sender.
>     
> 
>    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:
> 
>    [1]https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> 
>    The diff with the previous WGLC draft (-05) is here:
> 
>    [2]https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&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. 

Thanks Dierdre for the link to the diff with the working copy [0].

Looking at that in the context of my review for the previous WGLC [1], I'm glad
to see that the text implicitly redefining KeyShare semantics has been
removed.

I'm also happy to see that text has been added to list specific use cases where
standalone PQ (i.e., non-hybrid) key exchange is perceived to be useful or is
mandated.  However, that text alone does not address the crux of my concern
with the heading "Security considerations of non-hybrid", which I will try to
distill to a core idea here:  In {{{HYBRID}}, we say that (in the general case)
"the security community does not necessarily have as much confidence in [the]
fundamental security" of the PQ key-exchange algorithms as it does in (EC)DHE,
with the corresponding implication that (again, in the general case) hybrid
constructions should be preferred over pure-PQ, at present.  In this draft, we
promulgate some pure-PQ key-exchange algorithms with no commentary about how
these specific algorithms relate to the general guidance in {{HYBRID}} against
such algorithms, which appears to put the two documents in conflict; I am
claiming that we need to have some explicit text in this document to resolve
the conflict with our other document (which, we recall, is not even an RFC
yet -- it's still in the RFC Editor's queue).

I see at least three possibilities here: (1) ML-KEM falls into the "though not
all" bucket of "many (though not all) post-quantum algorithms under
consideration are relatively new"; (2) the security community has changed its
mind and has equivalent confidence in the fundamental security of at least
ML-KEM (if not other PQ algorithms) and the fundamental security of (EC)DHE; or
(3) the security community retains its concerns in the general case but some
use cases require non-hybrid/pure PQ even in the face of those concerns, so we
provide pure-ML-KEM key-exchange solely for those limited use cases, with the
general recommendation to use hybrids remaining in place.

I don't think we're in (1).  I suppose that the (voluminous) ongoing WGLC
thread (I'm not fully caught up) is in a certain sense a debate about whether
(2) holds, but IMHO we need fairly strong consensus in order to overturn a
preexisting WG consensus position, especially one so recently determined, so I
believe that we are in case (3).  (If we're in (2), we should pull
draft-ietf-tls-hybrid-design from the RFC Editor's queue.) If we are indeed in
case (3), I would have expected this document to include some text
acknowledging that the mechanisms in this draft are an exception to the current
generic guidance and are only expected to be used in specific limited
scenarios.  Perhaps something like (including some existing text from this
document as transition/context):

% Hybrid mechanisms provide security as long as at least one of the component
% algorithms remains unbroken, such as combining quantum-resistant and
% traditional cryptographic assumptions. Standalone ML-KEM relies on
% lattice-based and hash function cryptographic assumptions for its security.
% The sense of the security community recorded in {{HYBRID}} is that (due in
% large part to their newness) the general level of confidence in PQ algorithms
% is lower than the level of confidence in (EC)DHE algorithms as relates to
% cryptanalysis in the absence of quantum computers, with the corollary that
% hybrid constructions should be used in the absence of a particular motivation
% to use a pure-PQ algorithm.  The use cases identified in {{motivation}}
% constitute some scenarios where there is a particular motivation to avoid
% using a hybrid construction (though are not an exhaustive list).  Regardless, the
% decision to use a pure-PQ algorithm rather than a hybrid should be made on a
% case-by-case basis; the generic recommendation remains to use a hybrid
% algorithm at the time of this writing.

Additionally, I think there may be some subtlety around the new text claiming
that non-reuse of the randomness input for ML-KEM implies non-reuse of ML-KEM
ciphertexts, though -- a strict reading of this prohibition might, for example,
come into conflict with the DTLS retransmission rules where we do need to reuse
the ciphertext because we are logically retransmitting the packet rather than
re-doing the cryptographic operation.  Probably we can get around this by
clarifying that such ciphertexts "MUST NOT be reused in a different handshake".

I also agree with other reviewers that we may want to do more to ensure that the
security considerations for reuse of ephemeral key shares are sufficiently
prominent (whether via including them in this document or by specific
reference, though 8446bis §C.4 seems to only cover the tracking-vector aspect
of things).

Thanks,

Ben

[0] https://github.com/tlswg/draft-ietf-tls-mlkem/compare/draft-ietf-tls-mlkem-05..main
[1] https://mailarchive.ietf.org/arch/msg/tls/jKyjctDtgAo_tvbpC5Z2-nyW75I/

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