Return-Path: <ietf-dane@dukhovni.org>
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 5A101C01DACA
	for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 17:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level: 
X-Spam-Status: No, score=-4.398 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, 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key)
	header.d=dukhovni.org
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 068lF6QFC-_r for <tls@mail2.ietf.org>;
	Fri, 27 Feb 2026 17:37:17 -0800 (PST)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210])
	(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 CFACEC01DAC3
	for <tls@ietf.org>; Fri, 27 Feb 2026 17:37:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org;
 i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1772242627; h=date : from :
 to : subject : message-id : reply-to : references : mime-version :
 content-type : in-reply-to : content-transfer-encoding : from;
 bh=oGnEswHa8x+B9ouYhDk8vFex7643KzuqC8jnqlMJY8s=;
 b=mPilMCTmCxFLP5kVdWGZmILfoKxGfd43mwf/0WRkiJSIV070pDWHKOpE4bBbTXGY90jGL
 V1Pt76dbNAsLMHdcmR2A92gmcdMoJND2HAYzf/n7wZmZFFQsY+ABU+IIEs4zPwnJu/cSpvf
 yGNe/CsyZoEQqzX3Ny0eeaWQyJ7wp9o=
Received: by chardros.imrryr.org (Postfix, from userid 1000)
	id C7C0B938E14; Sat, 28 Feb 2026 12:37:07 +1100 (AEDT)
Date: Sat, 28 Feb 2026 12:37:07 +1100
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <aaJGw5tPigD_aaqp@chardros.imrryr.org>
References: 
 <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
 <aaISiXnAwn2gxNF8@akamai.com>
 <CAFR824wriXUfiboCvNDYH4SR=SKxSunHotz_QrkZn_dtbyjp1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
 <CAFR824wriXUfiboCvNDYH4SR=SKxSunHotz_QrkZn_dtbyjp1Q@mail.gmail.com>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: SZX3FJNABRYCH47NTGHHVATCC4LP2UJH
X-Message-ID-Hash: SZX3FJNABRYCH47NTGHHVATCC4LP2UJH
X-MailFrom: ietf-dane@dukhovni.org
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
Reply-To: tls@ietf.org
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_WG_Last_Call=3A_draft-ietf-tls-mlkem-05_=28Ends_20?=
	=?utf-8?q?26-02-27=29?=
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/ERJz-R4sKhDATXvScgpBf1KqUFk>
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 Fri, Feb 27, 2026 at 08:29:39PM -0500, Deirdre Connolly wrote:

> # Security Considerations {#security-considerations}
>=20
>  This document defines standalone ML-KEM key establishment for TLS 1.3.
>  Hybrid key establishment mechanisms, which support combining a post-qu=
antum
>  algorithm with a traditional algorithm such as ECDH, are supported
>  generically via {{HYBRID}} with some concrete definitions in
>  {{ECDHE-MLKEM}}. Hybrid mechanisms provide security as long as at leas=
t one
>  of the component algorithms remains unbroken, such as combining
>  quantum-resistant and traditional cryptographic assumptions. Standalon=
e
>  ML-KEM relies on lattice-based and hash function cryptographic assumpt=
ions
> -for its security.
> +for its security. Proponents of hybrid PQ/T key establishment generall=
y
> +consider it a conservative approach to deployment of newer post-quantu=
m
> +schemes alongside older traditional schemes, retaining at least the
> security
> +currently offered by traditional algorithms.

Some might recall that I suggested and support rewriting the security
considerations.

And yet, I see the above as damning use of hybrid PQ with faint praise.
If this is to attain some support from the sceptics, it must
unequivocally acknowledge that at present hybrid is the strongly
recommended more concervative choice, and that pure ML-KEM is a more
risky choice that should not be made lightly.

--=20
    Viktor.  =F0=9F=87=BA=F0=9F=87=A6 =D0=A1=D0=BB=D0=B0=D0=B2=D0=B0 =D0=A3=
=D0=BA=D1=80=D0=B0=D1=97=D0=BD=D1=96!

