[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Sun, 30 November 2025 13:08 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 0978892AABDD for <tls@mail2.ietf.org>; Sun, 30 Nov 2025 05:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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 NcUSWmpIikqt for <tls@mail2.ietf.org>; Sun, 30 Nov 2025 05:08:32 -0800 (PST)
Received: from mailout4.zih.tu-dresden.de (mailout4.zih.tu-dresden.de [141.30.67.75]) (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 E477592AABD3 for <tls@ietf.org>; Sun, 30 Nov 2025 05:08:31 -0800 (PST)
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=IBjxxdmNyUCPZ7hMv+ADdHUdaGrxRSoR9bCltE7C8qc=; b=BIzq9cWYRe9u1k3Sg0/ux+XWNT tYUxcXT8tR4/EGlWFI1OlcGYT7n4ONhQPqeBw3KH0AFA8oMESO7D4HaVjAMRJFCtVJdTh/uUu1qdV RQueNCi0OO7QB4JUE3Vf5vtU0rnfHhJopzJCLEEKLnH0BAZ3zQselqfYFWOkZITW75Y3KtsMkIK5V 4ylePrSX14IOU2e3O3NdREgNPcFf8PvqRPX2eLXHdW/Me4Tsb39tsujLxfYeF8MIWMfqUkkosByBO XvXthRppdaYW5iyQRZ0P2EID8cvkAVj8vzOVroQuS3SYXRRwD79Vwmd+ovVCJM+OT09YbNSq6mT9Y 2nUdjXiA==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout4.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1vPhAE-00B4gY-Eb; Sun, 30 Nov 2025 14:08:30 +0100
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.29; Sun, 30 Nov 2025 14:08:19 +0100
Message-ID: <8bd35743-8b7a-4f0d-8205-4a48e91d794d@tu-dresden.de>
Date: Sun, 30 Nov 2025 14:08:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: John Mattsson <john.mattsson@ericsson.com>, Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBNNsGEKSMcAyfnTyxCZLXxsBZT-u0adtn+5KyPMKm8wNw@mail.gmail.com> <20251128045939.466639.qmail@cr.yp.to> <CABcZeBO=JVUgHNph=yrv9ocTPn6Xd5xME=v=VAy-GiOaLgsihA@mail.gmail.com> <c3511e79-7fdc-4006-a6a5-f0b74645590f@tu-dresden.de> <GVXPR07MB9678CCCA73654597036A618F89DDA@GVXPR07MB9678.eurprd07.prod.outlook.com> <GVXPR07MB9678B6A380F89573725AF14789DAA@GVXPR07MB9678.eurprd07.prod.outlook.com>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <GVXPR07MB9678B6A380F89573725AF14789DAA@GVXPR07MB9678.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms000503050406010603060106"
X-ClientProxiedBy: msx-t420.msx.ad.zih.tu-dresden.de (172.26.35.137) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Message-ID-Hash: GG2J5C4PK6G7RGKMZNPCBBTFYIQZW2DT
X-Message-ID-Hash: GG2J5C4PK6G7RGKMZNPCBBTFYIQZW2DT
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: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)
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/_XRozJOy0mzNDtydJIk2B4mFhzY>
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>

Super naive question: how critical is this "application profile 
standard" discussion for MLKEM draft? IMHO, if it is orthogonal enough, 
maybe we can move it over to a separate thread?

On 30.11.25 09:57, John Mattsson wrote:
> If you interpret the word “standard” as defined in United Nations 
> A-HRC-53-42,
>
> "The term “standard” refers to an agreed norm defining a way of doing 
> something in a repeatable manner."

Is this how most people in the IETF interpret this term? I don't think 
so and the argument of mixing and matching definitions from outside 
applies here as well. IMHO, we should attempt for complete definitions 
of our own, rather than letting people import their desired definitions 
or interpretations from outside.

Besides, in my naive understanding (sincere apologies again if I am 
missing/misunderstanding something), D. J. Bernstein's concern seems to 
be on the word "profile", rather than "standard".

In general, I think we agree that there is an ambiguity in "application 
profile standard", and things are left over to interpretation, which is 
leading to misunderstandings.

IMHO, a collaborative way to solve this is to perhaps write a 
clarification document addressing D. J. Bernstein's concerns. I would 
assume that would need some lengthy debates. Perhaps that is too late to 
make RFC8446bis wait for it to resolve? Hence, a proposal for a small 
new draft.

-Usama

PS: While I am mostly in agreement with Ekr and John (except for the 
above UN interpretation), having seen the notice of moderation of D. J. 
Bernstein's posts and to be fair with him, personally I will not post on 
this topic any further until one of his posts land in the mailing list 
to give him equal opportunity to clarify/defend his perspective/position.

PPS: I am not super invested in this topic in the long term. This is 
probably not something I can formally prove to be correct or wrong. It 
is most likely just a matter of definition: one can define it one way or 
the other, leading to very different results. Nevertheless, I do believe 
it's important to resolve for us to peacefully work towards the shared 
goal of securing TLS rather than having to deal with appeals. So if that 
helps, I am volunteering to initiate a draft to try to resolve 
any misunderstandings and at some point in time, shift the draft over to 
one of you to move it forward.