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> Tue, 30 June 2026 21:09 UTC

Return-Path: <prvs=3641cf0f0e=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 1A2FF10B22076; Tue, 30 Jun 2026 14:09:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782853746; bh=6DC6dvKVP1oJ9BUhH+QkP+IhJVadrLdZaVkFTxlEOMg=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=AVupCMt8DW0E/J5+/oVXFPUkx1QLAwhjJZMQgtlm9+0MXcyPfByBYf46Z/Hj/MkE9 L81cEeo0dfoHwVt+Bx99mO+ukseI+oDj/LYcbD3gCXewKQWOU5dvltcggT0DdFrjpx Uu6EVKOKGBE9IvfF/pV1o1lpEjct6qt1ChljsOoE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.296
X-Spam-Level:
X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UkARD89ym4gs; Tue, 30 Jun 2026 14:09:05 -0700 (PDT)
Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) by mail2.ietf.org (Postfix) with ESMTP id 5EE3D10B2205D; Tue, 30 Jun 2026 14:09:02 -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=eHun86rm1DIj5e0yxwJH6YBHmiGD opuPNWr2FGsbhHU=; b=t6fmw3bLuo+yhRDjJzXKtmk9yQOPTYVVh6Bf66UosvR0 G/BbEayoERCIfW5/6vypuUOZAWRae6tCm+PgiMT3t+lNZIHw27qQrSE08yQ8bOTP /Fp15/M3d3YTER+xqAvVV91lfKbJgWTDTn4VKMlW6QVmlXQYsshMgvsl9jNNKC2I 6Fl0vL9KNfdTmQ/6clu9Ny4RheP/TEnN2AaFSr/ozvmLeJQNNywGiSir5i0FW7I1 HN1Clynt9cIsR1T6dZG/24blYQWTEJATFofbjEZYWBbcjaqHITUhzGgoqHHJTtqV LK35wbHo2dd4lczJ4TEnXSLaFzD/lWcQVXCBmgx5ZQ==
Received: from LLEX2019-02.mitll.ad.local (llex2019-02.llan.ll.mit.edu [172.25.4.98]) by MX2.LL.MIT.EDU (8.18.1.7/8.18.1.7) with ESMTPS id 65UL8YPv161246 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2026 17:08:54 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=bNnQ9ym407mAwKbWDJdjWC4bd6GC0ydS97+eZUQL9HwGdFApklKB1edWGSaq+xHfDt9dbuYbHZIOmClleYKkG4AnKQYQwIfHgQObzB8XjtF+sZEIZhgc77ZGEgsQmTeHUxe1dJpwHp77w9/9cfHqkgS3azvgJKHO0w7hJfjF/1T9/SnoEv5OEQ32snXfKBL6zQ8F21MtRETk3yakMKtxWoqDuBgaTN6QMsJ7cFlI5vqScPzpPCzdcmQlueBoa6D95hLTmaJ43rPINWAfqW3k/mqMt/TioriSxArg9J+/1Ys7isoR4Ri1LGU5yM1jn2Ibt7C6sVbWHl5MNJOGiOcdPQ==
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=eHun86rm1DIj5e0yxwJH6YBHmiGDopuPNWr2FGsbhHU=; b=yKPjf/3JM+Q92pT2yCdP+FHTV/SsLeYFn5humYFNjtwrdxJxg5V0r33PY0uZ/XLdeGRJtUbViC6h8fSFzAZ4MybAa2mm79LBlP6DdQnfftfgcmkLvzxaDNoDzor8PJmAMWpL+EpAp8vWV2tUeiDOggK3hdhwO1RWkR4ANAPzCZ1z18Watw+4Vfgx5zbvajnQflRqlNZhFWEkw+zMg33fyOWOVW4NsGK6slUCwPCsNrh7LzxAWbKr6EZ1lspnaS08/AciqI0reZjzetV5f886YuaG+Mix+AjeFHKw6rvyt97EzNK8ocPlHiHMy7tzDzabeSGGd7hTW2PavcTeJCgsJA==
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: Bertrand Jacquin <bertrand=40jacquin.bzh@dmarc.ietf.org>
Thread-Topic: [EXT] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
Thread-Index: AQHdCNNj1E7+ZKd1SkOAVHMYB3F+oLZXl5kA
Date: Tue, 30 Jun 2026 21:08:51 +0000
Message-ID: <0656002E-640C-4140-8A64-1547E6716707@ll.mit.edu>
References: <akQtnH-z417KPh12@lady-voodoo.lan>
In-Reply-To: <akQtnH-z417KPh12@lady-voodoo.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB1419:EE_|SA1P110MB1119:EE_
x-ms-office365-filtering-correlation-id: 627c2e21-1b2c-4055-a8a0-08ded6ebc968
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|4022899009|6049299003|10070799003|18002099003|22082099003|3023799007|4053099003|38070700021|6133799003|56012099006|5023799004;
x-microsoft-antispam-message-info: ljkxrPptYdAVhzIM3JO06fFYIuwvkerbQAMonwzN7pTC7vEbUQ6DnT+TZil1KjmlX7SspxUPe7N1OKVEj9DtDR9SKaHfRTV7Q8zAeUqtHPV8NyQZzWILn+QiEnto1ZKkCGNZw3et6G4oeJ/yLg1P1ZRdeZFndYRvlG3Pmx7FpgdamKDyM/zNQvxOb/FeefXRtX7Xu1Gg4oRp8o9Fdnvv+icNkzl7t4ZPUHimqOdLxFg4Z/LFXjxMuH5k1cjBWii4epwE4y82MY7FpLBdQUBgApc8Tc4nGuOIK1gLG5Z3hmQYNnx1v2f/FnBQJI1g9T3By/AtEiAJImBUjCOA/cD839U0jCU4ix4ofGxA2ggw1TCdrD95mhKytEZ8Z5Mrrm31LMA9HfMU0FvJJ2vaN6Avpfo00aniIGCI2A5eNFxSxu1Vrm24FQUMSpw4Dt0wJeIrRPp1cf9BPUe/zHupK6M+Z/MkBcVR8+RCq6uqfM2krWwEzzZDvsqOB3N1vX9jDJ2CcQCNaoWuhK9Kalv5g4hhWI1AOowGzYq54KkBxYd/aC8Dnv69QHaHd7UDxwEvL22ylSGegxdA8rZ0QrPgIEGwmuXeaM/T6W9QwmQTVOVu/K5MWa2hTkw533YrHthEqecsjPmgWC6a+cUo/hTjlgt4/3UJPFoA3gE0bXjQ31COebaFeibOTNwh2mDERAKSbHLjwHp+BV9Dxf8WYd1usRrktj74XTCKKRU1cSGrayHtBd0=
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)(4022899009)(6049299003)(10070799003)(18002099003)(22082099003)(3023799007)(4053099003)(38070700021)(6133799003)(56012099006)(5023799004);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: c9xdWEFqNmbtEfln+XAoIXeMdu8UyQXvU+qn0dzS8qRt2XXGgv57k9guEws3DUIpBQ47wBGaBlKX78zEagOLiUGIXKYKhp6HxK3jvwe03QgfM0PLbGz9RL/2GW1XX+X8KsjGY3oTgL3a9C6FTZXnvOakdGZEzMms1AgOqVDk+61UHK1tx1tECyzhto9vqEa1MCKC5hGn98m4rGaKVaO8+4RBDY4xILIuBRiCCpmcQBp5TMLXOqW7Blw/ZY0an5ETtssdKid7McohuM2uRjJ6dgjGkkiKdZ0OSXMxCIyKDcLvgfLCWWV+N9oOAmEH4WCCWMjkIE8bLK36M6aWvT4SGiGaY6FvKNynjgaupZt5H6TYtPyLwkKTcOpum0kQS5rlW6YqNCTZ51Tpq2v/uZqYiGxM6kyocpIcUv9n4FR3q91EUgELcSVcLEstK/kzZJK+4tVN0+nCH59an3bOpiws09gHZSBVWazwLqvz8zUj+oH0P3/zIHznR0C5MYugS38bK9j222NUe2WejBiqZkIVgGcdiCzNEMRSx4SDmT4ewsK7G6qF3bQZSjjDPne40USN2kjbdNMZbbZkh/OhTG+ya6PKupTq8QYnAPEsEjhLnbcbf7N+ixjxC2FEnK1qN21/OdXS5BIeckmyPeuaIji+3sxnZc1ZZguwmLgiLBQvWWsRB/nBH/3F0hqSqvAenZ4KTvwesth7S9wqRiclK1yxbkhcoUv7yuaylXvuIuo605bJXD6pDmFLNTu4JxrxVX9yeylGHw/8YjBWqAOvCpzqqfj00qIq6ki0hJ22ZhvZ5r5GBjIyIzUaOKZ3Xvqzt6Xphty7WnwdYnACZo+J7T0U0nVzdnayZcfpR6M6ma5arU83eUSeYFEw1vzRXnrJGhvT/lXxlsX5Dsj6FjeNnfC1BPS9xQhArJ4ueTTLNLV1wgzvHdtdDMdKpZVwNO48ijR+nsK3T6fY4oHBih0W5B1by+lkW748uYnSPUm+5jGty7qKKQrMPqagbAFs2ARaz5cueaLKnUFchVWKWG8teDo0CDbKegumfp2/ZIAOmKgRPiOWkUESYmtXHRas45jOMtb66DNdZ1ylCDboQ9pvXElkr7oOKlPRC5mGyAHyQGJVNGYGVJa5TQvTuim7y3ccwbuRtBF4W+7V+8kh/QRAax66buVWDnyPzE4A4/YsKZZgxBKKVGlgZuNDzJXzyxI6eB0JPaRa3cF73NbWNrAAAAISdFmGMyaLOIyWDoe4mshQKuXPVJSbzIFk1vAbKP7hssI6IbgozIFTME8nw/LzgKIuGmFlt4vCqQJGQRiZD7GFW9FHhMvERJkUvid/5+izGbJOM74Vu11D+ZUPmHRUVB4hMZW+JddEImrdKsSgY/mSKM7Fj7pG0NgpRYCMx7vhuWGqScw39Kb8M8cCeaYDAAsjjHuzWkxlgtxLrAHOa9FMY5d+e3sryjUQLAOQt8OwHkMQ/0rPYaCEqsq8Vxup7je3d8RIY+WmKIYnJyDpa6bS6S1fmnS3WhzI3yR/1yd4b8nL
Content-Type: multipart/signed; boundary="Apple-Mail-F11E74E2-1E1D-4011-AB17-B6414404BFE6"; protocol="application/pkcs7-signature"; micalg="sha-256"
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: 627c2e21-1b2c-4055-a8a0-08ded6ebc968
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2026 21:08:51.7542 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1P110MB1119
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjMwMDIwNCBTYWx0ZWRfX6xMYmcRMUoGE pVnQe/uf8Hsq2WlkT7NffxaAxd0jouFKns5UR+/1fjL6zp0deDsOzbfcF2DBSqqqeLL+8OY766N UviZtHt1YKryPpJA521mJxtOvSYkwFgHoEh6yNtRdxG3LYiVe+jrNbSMQ7obwKBLU2RXW3jafob dfvyB3doihlL7me6sWooJxD01QAQJ8F0flqD4iDb5ep3g/ZQmlGXwZWqaSnSOhL/mfcrpBZS3vJ Qd2Toia9yvyM7EJ/TzUp38pj8rIZMyVxI06R9jvx+ZLBSjuT7i7VeO/UqpB1ablc7jIx/fEFI9X tlwFDoQxKADPUC+JxIGI/I70DC4h5WRD0M6YMVawwlUUtZnl0ZNdDVmIFkdwaiYChHu+rJFf1eE gHr4FSzDuaU/6dGzM9M0SyYSnZ8W5w==
X-Authority-Analysis: v=2.4 cv=KfXidwYD c=1 sm=1 tr=0 ts=6a443067 cx=c_pps a=nMRZKKk9TE9jnVKm5NW3pg==: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=48vgC7mUAAAA:8 a=JCPcBFMWX2twG9vbku0A:9 a=QEXdDO2ut3YA:10 a=iGN-unowDNf44prktAgA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10
X-Proofpoint-Spam-Info: AW1haW4tMjYwNjMwMDIwNCBTYWx0ZWRfXzruVzHI9b6ih m1uaPOc8DXE1wGtCD7dLBTl1a7DX/Mx9CITKBsfSvpvRcqXeBHk7bIpH/0lBXt/E93DlzffbAIt p0CFWRsuo5lwx6tXrbiVcjmXEWrlXMXuEzm+ImIu6NRfVu0U5wJX
X-Proofpoint-GUID: wlaHM7K6gciFgmufWoFlyhWsJ0-hTfu8
X-Proofpoint-ORIG-GUID: wlaHM7K6gciFgmufWoFlyhWsJ0-hTfu8
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_05,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-2606300204
Message-ID-Hash: QPCBRE7QYMS7PPMXQI2ISKPH377QV6JS
X-Message-ID-Hash: QPCBRE7QYMS7PPMXQI2ISKPH377QV6JS
X-MailFrom: prvs=3641cf0f0e=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: "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/jA-AlgB7j6SzwXToBVM84JPrBi0>
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>

People seem to keep forgetting (or ignoring) the whole purpose of the PQ. 

If your data won’t remain sensitive by the time CRQC arrives - you don’t en need a hybrid. Just use your Classic ECC, experiment with PQ or not, and prepare for eventual transition at some point in the future. 

If your data will remain sensitive - then the difference between “it got compromised today” and “it got compromised with CRQC” is small, and ECC won’t help at all. 
—
Regards,
Uri

Secure Resilient Systems and Technologies
MIT Lincoln Laboratory

> On Jun 30, 2026, at 16:59, Bertrand Jacquin <bertrand=40jacquin.bzh@dmarc.ietf.org> wrote:
> 
> Joseph, WG,
> 
> I have read draft-ietf-tls-mlkem-08. For the record: I do not
> support publication of a standards-track document specifying
> standalone ML-KEM key establishment for TLS 1.3.
> 
> Standalone removes the only classical hedge, and that is the wrong
> default for TLS. Standalone ML-KEM is secure only if ML-KEM holds,
> forever, against both classical and quantum cryptanalysis and against
> implementation flaws in the field. The entire reason to deploy PQC in
> TLS now, ahead of a cryptographically relevant quantum computer, is
> harvest-now-decrypt- later. That threat model justifies adding a PQ KEM;
> it never justifies removing the classical one. A hybrid such as
> X25519MLKEM768 is secure if either component holds.
> 
> The proposal s a large bet on a young primitive. FIPS 203 was finalized
> in 2024; lattice KEM cryptanalysis is far less mature than the decades
> behind X25519 and the NIST P-curves. We have recent reminders that
> "post-quantum" does not mean "safe": the 2022 classical break of SIKE
> (Castryck-Decru) destroyed a scheme that had survived years of NIST
> scrutiny, and the KyberSlash timing side channels (2023-2024) showed
> that even reference ML-KEM code shipped exploitable secret- dependent
> behaviour. None of this says ML-KEM is broken. It says betting the
> confidentiality of the Internet's most important security protocol on a
> single new primitive, with no fallback, is imprudent when the fallback
> costs almost nothing.
> 
> And it does cost almost nothing. The classical half of the hybrid is 32
> bytes and one X25519 scalar multiplication, lost in the noise next to
> ML-KEM-768's ~1.1 KB public key and ciphertext. There is no performance
> case for dropping it. The tradeoff is trivial cost against catastrophic,
> retroactive downside. For TLS, that asymmetry alone settles it.
> 
> If the WG's clear, registered preference is hybrid, and the draft's own
> Security Considerations now point at the registry to say so, then we are
> about to publish a standards-track specification whose own text tells
> you to prefer something else. That is self-undermining. The honest
> outcome of a "hybrid preferred" consensus is to not ship a
> standards-track standalone spec at all.
> 
> Key-share reuse changed to MUST NOT in rfc8446bis. Welcome, but
> orthogonal. It resolves static-key reuse, forward secrecy and a privacy
> concern. It does nothing about the absence of a classical hedge, which
> is the actual objection. Citing it here is a non sequitur.
> 
> Once code points are standardized and implemented, they get enabled.
> The recommendation column is advisory and is routinely overridden by
> compliance mandates and procurement checklists. A WG standards-track RFC
> confers exactly the legitimacy and momentum that drive deployment. "We
> standardized it but marked it not recommended" is not protection; it is
> a downgrade and foot-gun surface that we are choosing to create.
> 
> Cheers,
> Bertrand
> 
>> On Wednesday, June 24 2026 at 08:00:07 -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. The main question before the working group
>> is: "Should the working group publish a document specifying stand
>> alone ML-KEM?". If there is rough consensus then we will push to
>> refine and publish the document; otherwise, we will stop discussing
>> the draft and not progress it. Please respond to this call indicating
>> whether you support publishing a document specifying a stand alone
>> ML-KEM. Please refrain from further discussion on this topic as most
>> arguments have been discussed multiple times.
>> 
>> Why are we holding this consensus call now?
>> 
>> Significant developments have occurred both within this document and
>> in the broader TLS ecosystem to address the concerns raised in the
>> last WGLC. Therefore, the third consensus call is warranted. We ask
>> the working group to consider document publication in light of these
>> recent changes:
>> 
>> - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a
>> separate consensus call, the WG agreed to promote the X25519MLKEM768
>> hybrid group to Recommended: Y in the IANA registry. Consequently, the
>> IANA registry will reflect a clear community preference for a hybrid
>> because Recommended: Y clearly indicates this while the standalone
>> ML-KEM groups defined in this draft remain Recommended: N. The updated
>> security considerations in [1] reference the IANA registry to
>> emphasize this preference.
>> 
>> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG
>> recently reached consensus to explicitly prohibit key share reuse
>> across connections in TLS 1.3. The new text changes the guidance from
>> SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding
>> static key reuse and its associated privacy and forward-secrecy risks
>> for ML-KEM.
>> 
>> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and
>> hybrid KEM groups in TLS 1.3. This supports other results which show
>> that KEMs are secure when used in TLS 1.3 and that hybrid groups are
>> secure even if one of the components is compromised.
>> 
>> - Liaisons: We received liaison statements from multiple SDOs
>> including  O-RAN[2], IEEE 802.11[4] and from 3GPP[3]  expressing
>> support for the publication of draft-ietf-tls-mlkem as an RFC as they
>> rely on the IETF to provide a stable normative reference.
>> 
>> Please note that a third-party IPR disclosure exists [5] against this
>> document regarding patents related to the underlying ML-KEM algorithm.
>> This IPR declaration has not changed since the last WGLC. As a
>> reminder, per BCP 79, the IETF takes no stance on the validity of
>> patent claims, and the working group may decide to proceed with a
>> technology despite IPR disclosures if it decides that such use is
>> warranted.
>> 
>> Conduct Reminder: Given the heated nature of previous discussions on
>> this topic, participants are strongly reminded to adhere to the IETF
>> Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep
>> feedback professional, technical, and focused on the document's text.
>> 
>> This working group last call will end on 2026-07-08.
>> 
>> Joe and Sean
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ [2]
>> https://datatracker.ietf.org/liaison/2198/ [3]
>> https://datatracker.ietf.org/liaison/2151/ [4]
>> https://datatracker.ietf.org/liaison/2148/ [5]
>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem
> 
> --
> Bertrand
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
> <signature.asc>

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