IETF Logo Mail Archive

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

Nicola Tuveri <nic.tuv@gmail.com> Fri, 20 February 2026 18:45 UTC

Return-Path: <nic.tuv@gmail.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 93BB7BAAE64E for <tls@mail2.ietf.org>; Fri, 20 Feb 2026 10:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ip7RUnE8Ju8f for <tls@mail2.ietf.org>; Fri, 20 Feb 2026 10:45:21 -0800 (PST)
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 28FBBBAAE643 for <tls@ietf.org>; Fri, 20 Feb 2026 10:45:21 -0800 (PST)
Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-408778a8ec4so1914525fac.0 for <tls@ietf.org>; Fri, 20 Feb 2026 10:45:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1771613113; cv=none; d=google.com; s=arc-20240605; b=VALRhsGGEGVhlQbjGVYtL1/kEd1TKhQnbDqEEP2OZD8uLVn7VNZhl7obRoKTjTxxAB 6wLid6r24fiPpEU2uqPGxENKOuxjMBD21nI86hNOkjiDimNMfo/VtgV21TiPTT+bKw2D k/N3CQThumQNL8TmNCeVoS2UilokXET/Js+6/7yJWOfEtPf2uwlrVnjEqTOWEmdXG0rB FGDNKr5oo3mmBN+opmzGZHU9RAQtldNIkPgbcCO8LpWNzuwHNWrwwp1OwL6sBnNuMKcE /2bS3zfiQ8WWzch1zmdem4rw1xi0JmD+J0xWptkKHhWi+BWGUCEjSotBdZcWOHzqLKFP eqMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=g3sBNwL3zJUfA3pq7zQZK8Q+IDuLSb92JUb7bmiShDc=; fh=iMQEz7fIE2XtFWqLUMEt8tz+aEDEJVSqHa2ftqd9oME=; b=Oz4V6SMzUh6i5in5wepbhT7vatIInPAmGU8yprFLpEpNSiy156OAXe//04RluMBQI1 bsMMEpFlW6hOhG9XEJP707j7/ynfcTUPFd01MTwTsihFAJCsY+jZVCwxYzXzQ2kA4k5Z v7Urz+c2bYDwX5lDiSakKWUWUlfBR/DZYCRh4f4gCMuobHSk10taLnTlkYaBLzlMQnt0 pTXP6n+hxDdAb18XEUEc2UOSADyKldIOWXOVdhbUG3XHAkeyVntjyb8WCYLDXfzb2MhP snLo9Qxem8w8QR2jvegtCscx8/rLnaVjCe2K6DXTEyzH3pwx9oGSktW27F9NUwrAYBbA 3c5g==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771613113; x=1772217913; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=g3sBNwL3zJUfA3pq7zQZK8Q+IDuLSb92JUb7bmiShDc=; b=HGjKyKnSG/f6bhcitp2HMszZe7aiSmqLvAQmk6rLysoyZ1SyAlzJpPKWTrxEuUxG3F CzHpn8Y0i5c+FN+UZvG6XOwvKHdEOZcnQhRLvSV5uSaXt3YQm4zu2ycR2zYMphI4DrYt xerFSia2uZLTn2N6tMZOkBWUl/trZjQMF1FOxJ3BFxihzlJtx9cB9kkETLrcv8wBKtyY oFzJwn/MwN7e4aE2kC0OL19BzlOdA4qpkGPXro+ZiYLx19iYo9Ob3zKoQJ9IR6Y0I20U NXUvpxzDp1EYY9kj2YtQJdphZYKGmf8tX3/Skb3TbqF9Poj+rBskiqG2Qhe04rkcmCpF Q/Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771613113; x=1772217913; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g3sBNwL3zJUfA3pq7zQZK8Q+IDuLSb92JUb7bmiShDc=; b=VyBfrkFIgjpMUZ5IgbImWxtIWgogeLo3J9k+3zR4xCbQ5I+8K8sgyXRoMk9AmpYaXn UG3ie+x4kF4cwBkfKVMkMvTE2FmktDio0ujRH6+jBHF9dfFgUDDCZa2dS+S83zo9Tzcf tMkQh0NSovZnjckXVNt2GajSpicXJ5PffvTI6ta7g0Uypy1G/1JvRM/7N2dYz/oYE76Q J5iAGCcw9dr2D9oKqSlQSGyrTPH7eu5DFEtKF1FOhH0GBi9usnqLFZmpNCuTmOTTaPMr VnMVfk66ScomPH+JhFV8msGy3QBnw4PYD7Dvz8asfzi4h1rVeongMV0PQW45L1ZfxwvO inSw==
X-Gm-Message-State: AOJu0YxHcf5B70ouyiSk7Xya3T10hA54DP11UTjdpz3E9yV5lf6+eiHg 7yNAJPmvc8PXtdHTda8dO1NCgmL9Y2K43giso0HWBMduLI9uByGnhEADlHHtkN50z07zfsgYda4 8EMEDQmeTqqpG4rzwRpMdTOPi9/tM7DPi3xdt
X-Gm-Gg: AZuq6aLCPD9P2pcpN9mx/bnL3PXuV0KfGnCfB0yu1MtnvHvZH4gt+tuytNVuIBIJC4K wkzBe1UaUcgpvPuokrTFV/fvi0//BQsJO/b4cXEUTVj9nD6UcC70Yv/BKxY2ANeCPihYblp6/tt jfyPfKpEZIkNZIONmyZ3NvvErScAqoWBEWzZDAg7ZHo8yfCrxyOvm9aDAeKbkDFLEtKKU4ZxbHN j3DiAY21uf5fz+wQ0FQGLlf+o01tgX+eTrRfage3SV29jxOXvzVPLlrzLfnxEXa4d8uQoPojY0r uFsiAyJspQDqAi/j2Qv849KumM8QRA+Sgnpfb1e2
X-Received: by 2002:a05:6820:1c91:b0:677:b586:d134 with SMTP id 006d021491bc7-679c465d017mr458931eaf.74.1771613113557; Fri, 20 Feb 2026 10:45:13 -0800 (PST)
MIME-Version: 1.0
From: Nicola Tuveri <nic.tuv@gmail.com>
Date: Fri, 20 Feb 2026 20:45:01 +0200
X-Gm-Features: AaiRm53_Gv7gpunbsHwj-GQz4rhUc4C1yb76I8fICY30yrZ40InIhvKka8CU2FE
Message-ID: <CANm5x_MMmBFW_1GUCK5cBbQtt=1tHQ4G+TcDB+_trCqhtr5B6w@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000502614064b45d2b3"
Message-ID-Hash: Z5XD4ABQYLXDOYYBPJGDZL4C2ZLMOS6C
X-Message-ID-Hash: Z5XD4ABQYLXDOYYBPJGDZL4C2ZLMOS6C
X-MailFrom: nic.tuv@gmail.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
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/6ZelXovULCzkXylW0YY8VDjJvdI>
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 oppose to the publication of this draft.

The motivation isn’t substantial enough, the risks of abandoning hybrids
are clear and substantiated by evidence, the gains in shedding a smaller
amount of bytes/cycles quantifiably irrelevant.

Adding options at this point further increases complexity, rather than
reducing it.

In general supporting this draft at this point in time significantly
reduces the security margins of adopters, contrary to the goals of this WG.

The long term goal of abandoning hybrid solutions to transition to “pure”
solutions is also questionable: there is consistent evidence to state that
this is not going to be the last transition, and that retaining working
hybrids will reduce the cost of the next transition and the ever-present
risks of ossification.

I’d also support Stephen’s proposal of a BCP addressing hybrid vs pure, to
have a dedicated place to address this topic across protocols and WGs to
avoid rehashing the same discussion points all over the place.

Cheers,
Nicola Tuveri

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