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, 08 July 2026 21:43 UTC

Return-Path: <prvs=36490230b3=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 B251511372171; Wed, 8 Jul 2026 14:43:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783547001; bh=b7RWPkfkSv9HYCylz8LuDpQjDLLywSf6zo/0Z9IoNqE=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=IVhKfRiz0IETblPLLTZSmkbQ/nAEn6NmYCpZbjkW48v7l6OOcKUfIjHq1lIA36MLq vdq/7JMVn9Ru2Y3rYbHyYM2/iblkP9kMaoqLycKoP5v0OVnQPk/uTSBNJM6tg1oASW wfKHpY0t47mrQ+NKcqk+X7+yCRT/4scAn/INin9s=
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=ham 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 0OHC8fdNs827; Wed, 8 Jul 2026 14:43: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 E77CE11372167; Wed, 8 Jul 2026 14:43:20 -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=CRWEQwFUDgCsYZrpzPlVAH+QCjp+ dk5NZcRrLizbqvw=; b=hFsICEKMbuDYg9vV+AckQuvtVncSk4E2O6c/ZUgMoo9t 11lVaEyoBOoc0T7e9f3eRINiggUiVCHkZgzf6k7U/9ZcEPdoZRYlwja5EeDZ/p9e I40NYoDlRax9McoKzht2kKNVY5IKd12Hco8l7+e2uvDKLwWLSt1RVSi7qzfuNvcH Vs6HlUw777xOMKgwnNAUFnjYMbZMD5tkMdoPTdPremjBg8qE+u6CC6B8ix35D2Cp k16YAjxGPZ6U59Lp3CrLWsA9h3XZfkw+9UtJyU3flV0G/MT/q6SCO84S02nffaQs /TpxhsNbeXVFcHW6iRaONKeqfbV67chm+FIZhrsi9A==
Received: from LLEX2019-01.mitll.ad.local ([172.25.4.97]) by MX2.LL.MIT.EDU (8.18.1.7/8.18.1.7) with ESMTPS id 668LhDFW158478 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 8 Jul 2026 17:43:13 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=hrpWgfI7uRaeykwD6C5Vb0AQnjdVTvkGgt5u3fQv78c2PeY3bj0gWKToyd4RXEzXmYQzKfY77GTIzm1yOxCfHaTOUWANZieq996MjwuzHNSDAEkKKZnQgEbN1RfGZu9ZdFd4oDyjpg+cwxVLViKAzwF5j07TEeGv2wIIoxs7T0TUPccdj8fYnKhdpieaeSKrms/V13Py9XxOuclRTpt9skP/xLtuuosEHtvcxP8VVcNf2/Y9fq0jnuYHfdywyOOhHoAOwDvgWZlpRfv925l9Are0IGQbR7sZ6HoxYTvxOk09lnW2QdjobBTtnb12+aTbxv+9sNRhl7/X/S7OcQj/Vg==
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=qlfI+DHhfCkDaTtpIZwYw6uqZjoagRCPW09IweF0xw4=; b=rqkOOu1J5QNg+FCcHHLIKks91bgbITmagrfm+1BWaHAO/foY4Ty1vT1qvfI5E0eqWfKQwLESGCnSVXyWapYvbajc18Q0hmIhN9qw21oUPMS3TJ1GnTmMszh5iJttQ8vCSh0DDSsKwqq4iRYfVkDZiESKxUb8gLL7VZMUwcy99b81WaiSRit/ve/MTk4bF6x8hNUYJXGo6pvzxoUihzJBH44c3YxnTp2O9Ym9gLKAb+CaKc44cCoXvOpDBWEOiNsASMWT2M8ajpAdMKw8RD1C66uphbwpZ5gZ/OpIBRjG040COV4atjozVC8kymkH5ojdL0K+QCof4IHOn6CNSSZTpw==
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: Orr Dunkelman <orrd=40cs.haifa.ac.il@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [EXT] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
Thread-Index: AQHdDxvlIcen/gSkw0ut9fhd4GXL3bZkH+gAgAAEcrA=
Date: Wed, 08 Jul 2026 21:42:53 +0000
Message-ID: <BN0P110MB14192A8BBA6DE3EA5652B30890FFA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg> <ak64iwRObZo0YJpK@LK-Perkele-VII2.locald> <CAA+_yBZA_5+y7oCKRebByTUPXCXsw9mkrf-8_g=u1Fm2QM0WGw@mail.gmail.com>
In-Reply-To: <CAA+_yBZA_5+y7oCKRebByTUPXCXsw9mkrf-8_g=u1Fm2QM0WGw@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_|SA1P110MB1053:EE_
x-ms-office365-filtering-correlation-id: e5ad7508-6874-4c4a-7900-08dedd39e802
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;ARA:13230040|366016|4022899009|23010399003|6049299003|1800799024|4143699003|6133799003|22082099003|18002099003|56012099006|3023799007|8096899003|4053099003|38070700021;
x-microsoft-antispam-message-info: gxHPTf3q9MmRj/4lxjMqZSWCxaj6pQ0DPvQhJ3bRNsBP/XSMUC6mGyYD1sxERoTsbMZ3r4kU7ZELwrIRKxbmyMvD5SCGfZYoLrQ0GDr+OjTE6SSx+0KXPVbq8fimn5m1PC7AyEP88HSgUb3eiiPvEhHeGYcvxaUVi5oIgotOydb0z8yr7/nlRUqhRm44HXWLbfa6qBnkIKsmIEbKJTDjAKd3B1kgcawHh9miwZ/C9AZmbQOVo6K+5jamn5mz0IAW57JYI3T5FGxL4QCC0ic+IJ+5JvR7LstqcFj6blXI8dNYYyP4a/kErX1ACV63M3va0WFdb9WVRX9/xXeSGnaiptcl3B722gfgi8UJ0gogEmw/QexFhfU+eDzSnZLWsTcxVj4eWkq2CZ4Kxwt5kNf6PmPE3qHyE2/aS+OhT/TVTYnx4YTtPkezuMY+CWlPAuE+7az1gm9h+5EdzKkJ1Ab+9QGZG/Bfrc/S0ZOrY9iKsSwMqf2OyIKEX4kIeBZV/Wiaz+5zWzC3XNZT9O7NjrldIc1SFgenvsME3FxapiXz9AUCZfaD1czDpx+JBDMGdgQHIPLUa5aAQk7L86/0eYwvJKpUgvZj5HPx48wsHQAURy4g0r2bPhyUkGjhj/PrVwpDq1JSqeXbEH5Q7CB2EXizqrDZmQYuRSMNLmIZizwZMMs=
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)(4022899009)(23010399003)(6049299003)(1800799024)(4143699003)(6133799003)(22082099003)(18002099003)(56012099006)(3023799007)(8096899003)(4053099003)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: GSxcQjNWa+sSXMp9WNYTfUWhS/rw6ftVLslvfki1X9V8zGPIbI6AYRsJTrQ23lpL/EsCXhGrH+coto7/tcAMRzLAiG8sA9qryzs55N9a1URZzCedQz0mf9f3yj7jujCAD9VB1UJKImpjhcjS3fSf871ofx2CsnpPS2DjSCYVR8Yznsl5J/AGcvomgYgcr3wDdUaFNgb8OEAc3N1bhGLtCPdIYczn3ordClz8VIHQ6Y1OTRVsjqc6/Xi0WgWp8cFBP3TLiY/EeuWV0mtRT/w/DSKYpQYbFfPO188lOUW00qWVP/jRLBQ5Wj1OzTgwKiUZVeLKLvnrpOSWof1PygaNUa59fPxjnQLDEv6+8/v3QrloPPm+tb4FMuDZb/s9o7R2M1RT4bveE3fx7ltdJtcPY2YDFg58yNiq3TPx+BQQ1IQyKo9uDBMs0hCxMsqKcSOexORtRqP6DmfLKT4QeYbjy0fXCxURcW2puV5cIZiBLyNXasqKylfQk5Moxt/AO3Neg05X8YMQFY9dSBZYjGcJEyTujUAqhdgH/f0sSFQrnvcB+dfezrvAj/V/VP8RiOqS+uMyH4IZAFFQi3lEjLBspKp3U3A4LSb9NkYCoTKq6CPwL2TG8o7gVjBT39DiykX+3QRKCEO9YNvFm1Wt+bjbYslDrxtpPZ9ngqcByvlt29p1QMJyNeaQXfFZW7TjbJymn/ukEHOFdf4wUQDoAg8ZYkUjfVm8wlfXoDs5qLzDJSZT/3o5PN6yZjaOmy+0WIJ+R20RpQIUDjM+nT/HD4BjrfAWPzVlQZ1N/w5SDZgkjCZFpMyGD28Slbby9GGqX3Q3Df2rrHysDLKup6DNNgtNmnJDtMZMQ1DUQkSwe2z+fXLRWgKYujFXCjARyxKWt57JFBxXhuLehTQ4a/2Wwz3FF7bSIQxsmS+rokzI+F89psRypLwTUnaZ1pagXqMXpg1itCv7YTCSJ7pZL7AKIM52RcyA/wm+oWi/R6jtH035bMOgfHzFqg3kI6hCvR5J9a67cFOlQNOKnD6GNWeX+TYmUOXaSP1sodR4opibld2hL3+oa7BSsPwTeWlXxFXwRbd7uJIj8hatFYica9c6MkhdiTUvhceaimONO6U/Ivf9ZpKDMgCVIj1WSfwYRENFF3eN/6/cVmWeyYxMqlIgE1mnG/janHUSpOXp0QJTdp8CIWpV7fGO7MjKO1gR/4xyf8Y7GFOxOuVjwxDpZFc/S/AX5rhusHdn1qpQzw6jsqc0qrLYSzOv/cFPWzURfqCHlX9Xt+i95KslMQVt+dD7y9a/zCPdeXpSKsKyjXj3yFNrq5jp1+8G31fZMaDfqebkHW7WcR8ag3y6f6QZO0QKmKTtuAeAAKGrK7tImn/TctgbZk3LcAxwiZveV4cSWWOtxt9jdgFPw96JfjA2tLyuLsHsKkQYr/aIMOMlqtb+joM8a2bA2K7l7Zg8oE4620G8xMfAdSVSj9jAgVCJsYlC6dMCTCXl7Fi77C9QYAkkt2TBXK2+7DhnDIEhdvydoGb9RunY3gm9ULgQ96bOsVn7ttmYNjv6kugNNx1qkt+k3K1FbNK3gzDyzQdmwHEZcfkrIBNkIlYEcxfDkzpsKM063mt8ZBhru6BjUs1K97ZqUv7MXIE=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha256"; boundary="_72DCC9DB-FC10-8043-840C-FDA2464FEB7E_"
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: e5ad7508-6874-4c4a-7900-08dedd39e802
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2026 21:43:10.8217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1P110MB1053
X-Proofpoint-GUID: Bt9Rh0EJIH8RjGhAnni_Y-BXuWic6pg0
X-Proofpoint-ORIG-GUID: Bt9Rh0EJIH8RjGhAnni_Y-BXuWic6pg0
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzA4MDIxMyBTYWx0ZWRfX+vcDCeIUBtQc OYLTFOmGXVGWozl195c2O35Hu/qIx8cbFMcaEAG0mGfj0+lO52NEV6EcM86KhRHVcpxbJwA5Opd nW2CbKzoGCTRQ1FXStWP8SweMJXoXWXxrz7urVRnohAHm8xtXn9nj1RKFYTT8CzXo3io2/MEWKb //KiwoIA/z0o2KQwl6b1NpDTSqnYsKe8hDXQcZ8j4FPTzvkQqRoy1dnNCpfG953mgl4QecV1wj0 7dBio8DaSC1nL1DGKpOfoJTK3MnPkSsKrEi0eGNV8YS/TEdnSANkP0Bk1qvYbjCg+zwdAgd/vhw d7j4M7BxJWg9VdssCUBhSJqdqrnwfnQ5ta4WlKfeGYMLGiy4uuW9G2X4v74iK0CFTKqh0Zf9ZZ8 oN/u5pbM4ec6vdp4AM9EE6NaX+Alzg==
X-Proofpoint-Spam-Info: AW1haW4tMjYwNzA4MDIxMyBTYWx0ZWRfXyY7ZdDydyMXJ jSxPC3++HEu28SV5WGDEbldx49K6qtqhLpKGU5EBZCMruqVi/F/q0Ihm9nEXted1OHpdpMtoycY tfJDlD9mQB4KiI0NmaniMGu6yBZBxv5OR0FT6PvVPjBkyFPk9UG8
X-Authority-Analysis: v=2.4 cv=Sq2gLvO0 c=1 sm=1 tr=0 ts=6a4ec472 cx=c_pps a=wUBDa1J3w8x80KTfM8wQIQ==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=RAioF0-LDSMA:10 a=VkNPw1HP01LnGYTKEx00:22 a=6J-vbcjw2OQC1sJBszXA:22 a=BjNBqyAe1Ba7-aRLu09B:22 a=WlxsqyjbAAAA:8 a=48vgC7mUAAAA:8 a=jpIRiGHsP9LSr3pFKF8A:9 a=QEXdDO2ut3YA:10 a=SvkIhbhmBDS4oAi8:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=yiS_OlLFfiXx3336nRQA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=TApCPVH6uDxqAy9nYJmN:22
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-08_04,2026-07-08_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 bulkscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2607080213
Message-ID-Hash: IQA74UALRUT5QQULJS76F4SJ6NQ7OWHI
X-Message-ID-Hash: IQA74UALRUT5QQULJS76F4SJ6NQ7OWHI
X-MailFrom: prvs=36490230b3=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: "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/5TJOYl5Jhjji9v8pJ6jKW1jXYjc>
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>

> Dr. Avanzi, who is one of the designers of ML-KEM, writes (in an answer to Dr. Bernstein tweet that 
> was shared by Prof. Bill Buchanan), and I quote: "In my opinion the issue is not implementation errors,
> they can be avoided with the right discipline. But, as a codesigner of ML-KEM myself I would not trust
> using it exclusively: what if it gets broken mathematically and in the classical computational model
> (I.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant.”


Well, if Dr. Avanzi isn’t confident enough in his design, what can I say, except that perhaps he should’ve worked harder back then? 
However, repeating the argument that people appear to keep forgetting or ignoring: 

* For data that does not need to remain secure beyond CRQC, adding ECC is great. There are costs, but who cares.
* For data that does require confidentiality beyond CRQC, adding ECC won’t help, because everything will depend on the PQ part, ML-KEM in this case. 
* People tend to know which of the two categories above their data belongs to. I suspect that those of the latter category do not want to encumber their implementations with ECC. While those of the prior — do...



So, for data with “prolonged” sensitivity, if Dr. Avanzi didn’t design ML-KEM well enough — that data is dead, regardless of whether ECC is bolted on or not.


I don’t bother with the case when the exposure-caused damage drops down gradually (disclosing now is extremely bad, next year — quite bad, in five years — I’d rather not disclose it but if it leaks it’s no big deal). 




On Wed, Jul 8, 2026 at 11:54 PM Ilari Liusvaara <ilariliusvaara@welho.com <3f784430-3143-4097-8b4a-0730c5c67898>> wrote:
On Wed, Jun 24, 2026 at 08:00:07AM -0700, Joseph Salowey via Datatracker wrote:
> This message initiates a new Working Group Last Call for
> draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key
> establishment for TLS 1.3.

I support publishing this.


I do not think hybrids are a major improvment. However, because hybrid
key exchange in TLS 1.3 is extraordinarily cheap, I think ECDH+PQ
hybrids should be used unless following security profile standard
specifying otherwise, CRQCs having rendered traditional cryptography
moot, or system constraints somehow make hybrids impractical.

And given how close my position is, it takes very little to tilt
the scale the other way. Furthermore, CRQC appearing would instantly
tilt the scale the other way. So I think wanting to use stand-alone
ML-KEM is completely understandable.

(My position on hybrid signatures is very different due to much
bigger costs, and is not even close to the tipping point.)


ML-KEM security, mathematical level:
------------------------------------
Post-quantum cryptography is not a type of cryptography, it is attribute
of cryptography. The candidates to NISTPQC were very diverse, and as
different types of cryptography tend to have different attacks (with
some common ones), one can not use failures of other types (e.g., SIKE)
or the general failure rate (there was plenty of "snake oil") as
evidence against Kyber/ML-KEM.

For the submissions based on lattices, the issues seemed to be mostly
bad parameter choices and some other details. Which is also to be
expected, and does not reflect badly on Kyber/ML-KEM.

The MLWE problem underlying Kyber/ML-KEM seems to be the best problem
currently available. Decent message sizes combined with loads of
analysis. LWE would be even better from analysis standpoint, but the
message sizes are pretty painful.

Cryptography based on lattices is not new. NTRU is from 1996, and LWE
(which is commonly regarded as better than NTRU) is from 2005. In
addition Kyber/ML-KEM also has extensive analysis as part of NISTPQC,
probably exceeding any other candidate KEM. Lattices are also a
generally useful topic, and as such have attracted a lot of mathematical
research for a long time.

And looking at known attacks, it is clear that anything besides
breaking ML-KEM-512 with extreme effort (not going to be worth it)
requires a fundamentally new attack.

Comparing to ECC, ECC has also seem a lot of analysis since it was
introduced in 1985, and is also based on generally useful topic that
has attracted a lot of mathematical research over a long time.
Breaking the cases that have not already been broken also requires
either quantum computer or a fundamentally new attack.


ML-KEM security, implementation level:
--------------------------------------
Unlike mathematical level, which needs to stand the test of time, the
implementations do not. A well-done implementation is good right off
the gate. A badly-done implementation will remain bad even after
plenty of time.

Implementation quality is not gated by algorithm understanding or CS
theory. As consequence, implementations do not really improve over
time. More implementations get written, some of those are good. And the
bad implementations tend to patch the worst stuff (but likely never
become good).

Fortunately, implementation quality of ML-KEM in TLS is not very
important: ML-KEM is not prone to to implementation flaws so bad that
all security is destroyed, hybrid or not. The remaining flaws tend to
be either strongly mitigated by not reusing keys (required by
RFC8446bis) or destroy interop. Hybrids are practically useless here.

Comparing to ECC, ECC also has history of all kinds of bad
implementations. And some forms of ECC (thankfully not supported in
TLS 1.3) are not resistant to flaws that instantly destroy all
security.




-Ilari

_______________________________________________
TLS mailing list -- tls@ietf.org <8454960a-8e7c-4704-855d-d3a28353fde0>
To unsubscribe send an email to tls-leave@ietf.org <9ce685c3-97e6-42b6-bf52-fee2592f83f4>

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