[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Mon, 06 April 2026 14:15 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
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 69357D6FE063 for <tls@mail2.ietf.org>; Mon, 6 Apr 2026 07:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775484926; bh=NYfSQS9VDEmCQX2h6uMP7GTjajlFdWIN7+gxVtaUbeg=; h=Date:Subject:To:References:From:In-Reply-To; b=WEkgUgBflPohBvtMhJzUBDugPXKqmFXkyBW7LLY1uniGrGAl4cMAk8drVezTTSgGC 0fk2OM0gektxmFzVocBQED0hTtDQvRih/kYbUV7XX+0PcL6gA/Cg9KmxBEQY8k/HNw doFadTbVIx4l6ZCIE1WnFLPufqH1urdXd2As1fwk=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=tu-dresden.de
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 K2w9hPBuPru9 for <tls@mail2.ietf.org>; Mon, 6 Apr 2026 07:15:25 -0700 (PDT)
Received: from mailout7.zih.tu-dresden.de (mailout7.zih.tu-dresden.de [141.76.32.220]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id BF6AAD6FE059 for <tls@ietf.org>; Mon, 6 Apr 2026 07:15:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:From:References:To: Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hDj0xDQKq3DHCmtsVKkdH6rnQvLZlOKcasMPYxDUK/M=; b=e6dYYukkohPx08fvm+2Jkd+y75 8jGqQLVXl+sSRyPKwDMqCPvVja/jakS83ED5tZfqQWHOLx4GJ0R0DZAHnXn/gAV5HxYjrYSVbJCN3 HCiBZKvFtlFEGtGKF6lPYp3UxOzOs6VJcbgo4WLLMyc4BiKCzDhlSY8gG6HTFAX6yCYZUkHpwKPh1 s73Kgv0GO20/xJjzQMIZQMd/xsS5l9vpXAu98iJ1Q3PfMrhofJ3uDlimeH9BGc03GEVPUSBmDirdT vogGcmTPEONCgbj548g5CvXMVY59m840MLsFrfeu0WN7jTggq+TLbuDtej4GEaNM89vgaUmGXqlA1 oAkFTb0g==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout7.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1w9kjY-002Dab-2e for tls@ietf.org; Mon, 06 Apr 2026 16:15:25 +0200
Received: from [10.12.5.228] (141.76.13.149) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Mon, 6 Apr 2026 16:15:04 +0200
Message-ID: <33967c18-be6f-4902-8dbb-9d75e4936665@tu-dresden.de>
Date: Mon, 06 Apr 2026 16:15:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: tls@ietf.org
References: <CAF8qwaALDXR6d=jLD46wXmKHDjyj=OdJ1X3a1AgxF+ByQceeMg@mail.gmail.com> <697d6134-0083-4933-8531-9be49118be7d@cs.tcd.ie> <adCCIZsvHqgci5LT@chardros.imrryr.org> <597455e4-29e1-46a0-a9a7-b87c5adbaec7@cs.tcd.ie> <adFBMGhVMOl2eptE@chardros.imrryr.org> <34c6c882-4cef-4350-9afa-0edb0b460eb6@cs.tcd.ie> <adHR1YEW-mPEb_BT@chardros.imrryr.org> <MEAPR01MB36540326A63FD5EAB70F652BEE5CA@MEAPR01MB3654.ausprd01.prod.outlook.com> <CAPxHsS+fv2S_Ydub24AHnFJUESxkr=h1me5NEtdsZ4bCqAip-Q@mail.gmail.com> <5b703cb2-721b-485c-963a-c6661b40c4c8@tu-dresden.de> <adO2k_hAp0vBtS49@chardros.imrryr.org>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <adO2k_hAp0vBtS49@chardros.imrryr.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080909090601070706090801"
X-ClientProxiedBy: MSX-T416.msx.ad.zih.tu-dresden.de (172.26.35.136) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout7.zih.tu-dresden.de
Message-ID-Hash: CXCXNXQEGZIQ5YTDD7BRJBYLJM3EITEC
X-Message-ID-Hash: CXCXNXQEGZIQ5YTDD7BRJBYLJM3EITEC
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
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: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"
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/D2C_TO2eZYPnVlxbZp9uNpsxxio>
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>

Hi Viktor,

On 06.04.26 15:35, Viktor Dukhovni wrote:
> On Mon, Apr 06, 2026 at 03:11:23PM +0200, Muhammad Usama Sardar wrote:
>
>> Also, as a counter-argument to my position, can someone kindly show me
>> that pure ML-KEM is /more/ secure than hybrid in the context of TLS
>> protocol? Thank you.
> 65536-bit RSA is "more secure" than 2048-bit RSA, is that a compelling
> argument to never use 2048-bit RSA, and always use 65536-bit RSA?
This is comparing small apples and big apples whereas the comparison 
under discussion is "apples concatenated with oranges" vs. "oranges only".
> Any choice of cryptographic parameters is ultimately a tradeoff.
>
> Admittedly, in this case hybrids mitigate additional risks without being
> unduly impractical, but not everyone sees those risks in quite the same
> light.  I agree that hybrids are prudent, and would like to see that
> point clearly stated in the pure ML-KEM draft,
Sure, hence my request [0]. Thanks for support.
>   but I very much don't
> think standing in the way publication is sensible.

Already clarified to sufficient detail in [1], so needless to repeat.

Best regards,

-Usama


[0] https://mailarchive.ietf.org/arch/msg/tls/oiVmp3PCo9H6aiugPQ8aVFztvVg/

[1] https://mailarchive.ietf.org/arch/msg/tls/q4nNjdrGrJv-4s1JYVHz41WJ2Go/