IETF Logo Mail Archive

[TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Wed, 01 July 2026 02:38 UTC

Return-Path: <prvs=3642f576da=uri@ll.mit.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 8761810B4D3C6; Tue, 30 Jun 2026 19:38:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782873500; bh=ObkbiC+AfLSh3Xy2W8Bo7Mght485dHxBJ0pivcWcJwk=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=bpNNMa78bY1ajAtM4AX1fxHtlRwJHJimw0jGrMHogp/syKgZwfLfWXGMVD4U1mb+g Vy/qmDWfXC76A+MqLJqhWzj8B2tWD62widF3dJJrJTy/LA1m7LtZa0ZpgsJp9wkG0l sXKUQDieI/UtNfmOjCcBUl+JP28tq4E0ChwLCEps=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.295
X-Spam-Level:
X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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_HELO_NONE=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=ll.mit.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 bF09TqyiBC91; Tue, 30 Jun 2026 19:38:20 -0700 (PDT)
Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) by mail2.ietf.org (Postfix) with ESMTP id ED19210B4D3B9; Tue, 30 Jun 2026 19:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ll.mit.edu; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=dkim3; bh=RPi6dEmrXp2rLa6lcp328rlHruvV ASM0+oYDMtf3aPQ=; b=fPqkTfMZKBPw/cCNgQ8XJFT44GYO3w9jaBY48LSxbJxa FfVzRkJKIAIuriywk/iaEFn/9haF7LgD/56RX6v4DE88NVBBNZTRVIkbE6mMtOyQ 9EGgXFR3IyPa+yN1ZuNUfmPnLOFy3h+n0ryVQ5iExHC5tO4ZDftQMCh7G5UvpqIf tX/yImATuuf8wHoin553AHE4gUeQSW2qT/DnW5E2r+aDm+KFhjXmbO3lVWKHYNim /QWH5xCf1pAglhoTDNL7nvrpMNsY6jcbgboew6F8tk5H+Qy+7b2u2HtInyK+YvxB L2CB3cjSparOjaUI1xCMumgkrdPaAW4zPoA5FuaooQ==
Received: from LLEX2019-03.mitll.ad.local (llex2019-03.llan.ll.mit.edu [172.25.4.99]) by MX2.LL.MIT.EDU (8.18.1.7/8.18.1.7) with ESMTPS id 6612cFbg040368 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2026 22:38:15 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Wtu53vCc93q5BatAyaImYKjdPzGcvBiQ+jBL+1fSqp5F07U9/NMLEYe6vOvAsMljukbqFTMmfe7eQuevSXRfB/KlOldoo/cTt3iv2/Udov0lTapox4xr4iDHhLtiAD0Jm+ZJ+pYqFntQ6V4/rwXBCHL5BSQnwkHmLv+BxbQKxI6hVf+ch1iHwO1uoP9F8OsMQt/QIaOteuj90pajgAys0ConnyDnzFEvxDkZsuSm493kjNNSbyPEo6QEXgqvTt5M0ZKKZ5JdZa/W5ZfvbXameWXy7M+ffK8CLIwFUknofR/D8KMr9f+68tan5eYqmZPU9+VWq/9NX7Yx1FFK+8cX8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iAhXxztU4zuuefo48KzfKOMHpMlmxafmZKkuAQCs7zs=; b=QZX9GaRLsMfhrcyWaQ8atQISzFOqJoTm2K/FoP2bednIw3mcyTt3Bgr0DetenFebcZnSAaMcTq5P+M+NSfNcFqjAR4is0Edvyu6p/+xf+2BgGZK9xk6xOGCfoMUz1zdYGZGPJH2FQGh/2PKLDyeEQa8UQYL9wOypTNwrBxXJAf4PmTTHF9hsHK8O4Hl2Unsgj86KjiaQa+k+sxi+RegDh7pTgd4KAfFjbwANGf4YNXsaMd94B6ig105cuGXvz2CwEAYnb+6KdYsxkLIXwmzC2I8+krMfV+7Vv5MU7bMsRdNrlS/LETnecL9Zzmk07TxBSquMfge5GZNjV7LThl0ndA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Rob Sayre <sayrer@gmail.com>
Thread-Topic: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
Thread-Index: AQHdCNVUgDe+LhU5T0y2jOb6AzC7IrZXmvQAgAAA6QCAAANhgIAAAWqAgAAY8GY=
Date: Wed, 01 Jul 2026 02:38:12 +0000
Message-ID: <BN0P110MB1419E532C18E7B7C788DEC2290F7A@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
References: <CAChr6SzH_wAwG2U0Jw3vbLxOW0VJNFkPeyW7BqG1_z-u3KLd-Q@mail.gmail.com> <2272969A-E10A-48B0-8DD2-8F29BF46DF4F@ll.mit.edu> <CAChr6SyviobJUdNeVFuD5-bFBeo6N+0xoPqTDkcd8o+O1=SOAg@mail.gmail.com>
In-Reply-To: <CAChr6SyviobJUdNeVFuD5-bFBeo6N+0xoPqTDkcd8o+O1=SOAg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-reactions: allow
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB1419:EE_|SA1P110MB1248:EE_
x-ms-office365-filtering-correlation-id: 00356845-499f-47fa-fb28-08ded719cbde
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|6049299003|8096899003|56012099006|4143699003|6133799003|38070700021|18002099003|4053099003|22082099003;
x-microsoft-antispam-message-info: K5LL2z2VIgMZXP2e6f64zmokWBnl+6qZTUz9Y9QLhKVYlCZ9rgXmyntvzlJYGdYxUUaNaDK8l8JjmyGEDKv8gojosZTM7hpuBfrON5Yc8cLWKSwsbLL3UK4477D/v3Id8ed2k9R5TDZ+mYHw33f271wLNFZw6IhRIHlHMIqSyNGFIKbWbG1N7xueFg7AKrJ/L5zIkx5xce5Pewdfbk7w0D1d0JUVY1DaOy5AWF3ffxUrn54h4Sl5VCKtYQ6iPssacuYfjhDyz/gxHJKhCPJcpXs+98pU5IPEVomSBM6yPf5DNaNfjI04VnpRtDpIpc4VSj4euvfivs8Z8HFgqaGw012esJmZpwh8j3kDn3WXAlQdd/0i+0s2Nt3mGDhbS6e65jIP7WJEz/WJj3l9Sa8Tdy++SKWDdzyMaRC5Mcqa8h7dckzHDwC1GXaE2QZSgF7cHIIKslDr4JPfX9G+aBRmOMH3Uo68EZLGhxFVLomb191tpOWyX6rrZ3GHTxruYoyVU/W5yH+N/WSDWCLtVL/j2I0zE7expxef7iSk/j2C3bBiJkWrQOaJPwxPynsyOekm7nHvgXc7w0Z++W2+hTzGa+TZgY8woM5wjZci2CpnoHD7+kN/2UuhhBXRs4rutltnYohMMetinR5ySgel8Ck8zino8GIvaQFww98383APbLQ=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(6049299003)(8096899003)(56012099006)(4143699003)(6133799003)(38070700021)(18002099003)(4053099003)(22082099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: PhkW59zTPM4G1VJjWzL6saguPrGbkScOaLc1FEsBu/W/mRWE1Tobpz+niqvC+ioftpzKSqoQLTUV/IZXcMwkPsGXBjmLwp4qVE1J7cK/Akxbsb2uagzLdQch1Ld6BncHfKM2oQsyBqJUCr6b7wh/vrtQMFuLj7shvMpdSedFIUSKcHHzWDh3CkMN7jOm2YgqczsfwOYm50hKI2+rHAzQFIkfXxrzQ1oDl0mN4OvzCYsJHnnwEwrdpXu7YR0Yd94v1xrA7TWlL4lQWng6AcYBjl4nIm+6XrXXx+57UKjJGSqprv6PJJdZSm3XLl6T9FTEhv3J7fxTMLzxkEXa0ZeY7resTB7pRRonaXllT8PQSdJWhHzCTrpsHIXEfWfrIH9ItQYStiCyVWNF3srtiiLjHvuRpspORbz6jcTBWfN2jsbHx41pa8CHHOdc19xSwaPTNxjFAU+IC5dWNSVQXO0Fga5LHISmx9Bu3rUWkcy22Sf7gv3KSWgVJ79Wc1KAcXLiQwpsr7hT4KPyQfXGCbYbgDL19CI1e2MvNFMzW7U0flw9uphyyrRZBGfSaiccjrfAuZlwJg0y7HuE1h7xY9jDgVHEOeaOMzcTBSSU+Id9VfC/AczD5fCRqlVSr2CLNmX9Kep5badw01CQ39WCHLm7KkPkVMdN7lIECdgtf+nSzTB9PzvKyLpx6q3TMxFRG2HW+Qne0oWQVsr9QhlBaEHMML+VsVxpP22D4jVZ5Fn87cxP827HrSDY/dEkK6hVeFlrXmWghqSnrrQfWHQ+CE/ubP0DE2rWGF3KqWGGhx1iw5fo/W3I+tyP+YBdEoV5sMgZg+doSJZ5krAwp0LTABWVjbf6xJ0emnyPLptlEXIxfnRfwbJLjDzpVj34CRbk6OE904IuFaskWJ8RkvA/kxWTXVELzjQo2cy2FjWk2Q3ctC15WxUUvaVJEerquE23hN1pR23HcU3AKDCkvkuSXsl1y0fDiQBkiAYeWI36GqGJiIqUm5ypK5OjgZzslSQGwnrD1aWV8blJF8eo2uVVnTJ4Zht5S8oYib2Zafp+TReT6KRZR+0WPtqVvrKf9OwvXx9mRa14o6fM2+wY67YKALByqaMgIDxaQjWtNg70uySKgi848rL5FydlBtuaNNdKRlAQp2RF1Gw4aLAoHTSb/aQRE41vFLT8UEibChKqnBgns0RvR+ol601OTKuhdNsP1rZSk6wOtxbDaW5XDsM0AKZIC4yB2vKslThz7k+kvtsb0QhiAfJteQz9bYdkFl6/zKaYP1fWFPBokXCczfnJTcW4q9hbvR5ukZetR+6R2WJ2UVVMiK6cUrwPHFuxerYAFPSdWDn8FzvaSo1mxY2V1i/sFx9NUeNrgplKBqgMLxRVzKck8uaGvZRO3qZtkPREdq1Xm2Kpd8+HiU7u6kDDTK+DowQLrY2MkP7zVDkf2G1tNFGfIJX1HojQd5qJs9/xvyunx4wMtFIbBQpXhcWBqq98+kd4lomGKQVe/Q0Omh2iET33Fz2Xg7ubLLlTMqyzyWpITzatS3q42sY/Ws4rLQt34L/IVLhqeDvbLeb7Xdc3+Ox/5QzC9yy2XRBh7Df14KzB38stvpWb5cs9rwFAR/m097oDMIEWNTV/gsTMhQbHR/Qns6pS6um/N516TWGSWjLA
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha256"; boundary="_218948C9-980F-E741-A77B-F1D6D4EFBD62_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 00356845-499f-47fa-fb28-08ded719cbde
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2026 02:38:12.6633 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1P110MB1248
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzAxMDAyNSBTYWx0ZWRfX4ELdD4RHfbSD KOcmv9+Fe5NAVT9urzgJnECGS0ZODwWHRHivYTZ8T+PFVnPYacQCgvG/yQMfaWZPjWn2iIB07Wb xprD3cAG6kFXcFPduD3CfLn1kKrmTG1l6oS7NvndzdYJ5Xx6ZErx0QcX6ZoQeTU12Ffdl0pO4aN CMxoctC76LHvqbB0/+sYGXywTO0qDjaPUaxqQ++GFXXGys0DWqCH6KTYw6hH8JL1sVTK4c3TRBL 8WLzllNpmQcutTEMFlriDvj1H5121CuBtpnj6g67U0AZMP36xmT8h3mLvsgeI+PV0Rz7b4ijAfL IDyvb4syBy9V4RLUf/oXssQdj/nwXakw5eUEWI+9rCaQCcjLKVURkwRdiI4/PiE7N+CX4ZwjmJg 1XLbqfZ8iF3ULIl5gUcETxiEOwgoMQ==
X-Authority-Analysis: v=2.4 cv=KfXidwYD c=1 sm=1 tr=0 ts=6a447d99 cx=c_pps a=gKe/mLUEfoSu6txfIyclRw==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=FelO9ux0wxsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=6J-vbcjw2OQC1sJBszXA:22 a=BjNBqyAe1Ba7-aRLu09B:22 a=-bAmemOR44Mt9QRTPUAA:9 a=QEXdDO2ut3YA:10 a=b_PkhHo_DU4e1CLEDOMA:9 a=7a5eYKphp0LqWl0L:21 a=_W_S_7VecoQA:10 a=yiS_OlLFfiXx3336nRQA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10
X-Proofpoint-Spam-Info: AW1haW4tMjYwNzAxMDAyNSBTYWx0ZWRfX0nFXcy8jkoKM YiJahA3Cfgrj3l8lMhWGj7eg88PYMvsRAglBhIygMmeT1SBrlCXyNLcAPtfMTE0E+MvZmsX++j8 DGHlf8gIvx/ICpILuXAZpw9vrXT7Y2EfcY0evGEE0+Ga7oBWpKj0
X-Proofpoint-GUID: XHmkJzMX3TS-lKdbrYHhJUddKSNA8Ql-
X-Proofpoint-ORIG-GUID: XHmkJzMX3TS-lKdbrYHhJUddKSNA8Ql-
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-30_06,2026-06-26_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 spamscore=0 malwarescore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2607010025
Message-ID-Hash: VEMMWGVWOSZMAAUXEQTJ76QHZXHA5P4R
X-Message-ID-Hash: VEMMWGVWOSZMAAUXEQTJ76QHZXHA5P4R
X-MailFrom: prvs=3642f576da=uri@ll.mit.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: Soatok Dreamseeker <soatok.dhole@gmail.com>, Bertrand Jacquin <bertrand=40jacquin.bzh@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>, "draft-ietf-tls-mlkem@ietf.org" <draft-ietf-tls-mlkem@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
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/qzqktXO14BLyAvlVhz1_xyFkFmk>
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>

>> If the data must remain secure after CRQC - you do not get bonus points for surviving only until CRQC. 
>>
>> People explained eloquently enough already why using SIKE as an argument is bad. 
>
> I don't read all of the messages on the list.


😃


> But it seems kind of curious not to do ECC no matter what you think.


Hmm… No matter what I think? ;-)


> What's the reasoning there? It's not costly, who cares.


In theory, adding another independent algorithm is beneficial, and at worst — useless, 
but it doesn't in any case decrease the security of the combination. 


In practice, however, it well may reduce the overall security, and here's why — in no particular order.


But first — mandatory TL;DR


The core question is: Do we trust ML-KEM? If yes, adding ECC is an unnecessary complexity. If no, we shouldn't be using it at all — hybrid or otherwise.


My reasoning in detail follows.


Increased Attack Surface and Complexity:

* Every additional cryptographic primitive introduces new attack vectors. Even well-understood algorithms like ECC can have implementation vulnerabilities (timing attacks, side-channels, etc.);

* We know how to do that, but DJB’s point was that there could be libraries that didn’t get a clue;

* The integration logic between ML-KEM and ECC creates additional complexity where subtle bugs can undermine the security of both components;
* Real-world implementations rarely achieve the theoretical independence assumed in security proofs.



Certification and Compliance Burden:

* Hybrid implementations require certification of both the PQ and classical components, plus their integration;
* This doubles the FIPS/compliance validation effort and timeline;
* Any updates to either component may trigger recertification of the entire hybrid system.



Codebase Maintenance:

* Maintaining implementations of two separate cryptographic algorithms increases technical debt (for no good reason);
* Testing complexity grows with hybrid configurations.



Combiner Function Risks:

* The method used to combine keys from both KEMs is itself a potential vulnerability;

* Yes we know how to do that correctly, but didn’t DJB repeatedly commented on the risks of some libraries not getting it (ML-KEM, for example) right? Shouldn’t that logic apply to other components as well?

* Incorrect implementation of the combiner can actually weaken security below what pure ML-KEM would provide.



Performance and Resource Overhead:

* Hybrid systems require additional computational resources, memory, and bandwidth;
* In resource-constrained environments, this overhead may matter;
* Large multi-user servers may not appreciate this overhead because it reduces the number of connections per unit of time, that in turn reduces their revenue.



Infrastructure and PKI Complexity:

* Hybrid systems require maintaining parallel PKI infrastructures—both classical and PQ certificate chains;
* This doubles the operational overhead: key generation, distribution, rotation, revocation, and archival for both systems;
* Certificate sizes increase significantly, impacting storage and transmission costs;
* Organizations must manage two separate sets of trust anchors, policies, and operational procedures.



Implementation Footprint Concerns:

* ML-KEM alone has significantly larger key sizes and memory requirements than ECC;
* Adding ECC on top further increases code size, RAM usage and storage requirements;

* FPGA implementations may not be able to tolerate this;

* For constrained devices (IoT, embedded systems, smart cards), this combined footprint may exceed available resources;
* Devices that could support pure ML-KEM might be unable to accommodate the hybrid approach;
* This creates deployment barriers and may force continued use of classical-only crypto in resource-limited environments.

* This already is a risk because of the orders-of-magnitude increase of the pub keys and ciphertext sizes, no need to exacerbate it even more.




False Sense of Security:

* If ML-KEM is fundamentally broken, the ECC component only protects against Classic attacks, not CRQC;

* This fails the main purpose of going to PQC;

* If the data needs long-term protection, and ML-KEM fails — you've already lost (see above).

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