[TLS] Re: RFCs on weakened crypto are not fixed by warnings
Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Wed, 08 April 2026 22:49 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 8B14AD86607A for <tls@mail2.ietf.org>; Wed, 8 Apr 2026 15:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775688571; bh=NB9DUdJw36Meaa91XzGmI/XMEoYmvd+QAxpsSAyERMo=; h=Date:Subject:To:References:From:In-Reply-To; b=ZAaQMYCpytDIPiWla8vEuY4tG6v0ylIC4dpns6J9oOT2K2s6pvj/3469t6JlwGTVW 5zP+4POuhHE+vp/jybAeme0iPOv4h2k0Z4fboq1n6McyfjsVDvXWeXkrzR8xx6Otbn wzXOzhC0K3VLM3ul7FQ6oTJ69MEkSvg1ZVzcsMPw=
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 pUNtnHeKDQjI for <tls@mail2.ietf.org>; Wed, 8 Apr 2026 15:49:30 -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 A7379D866029 for <tls@ietf.org>; Wed, 8 Apr 2026 15:49:17 -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=3PBFQnoaM+tV+GmaEB16ZHzR8O0Ve2PTl4xRfkCp9h4=; b=sFrlD4ZXhImd5eiNjjki5S7Zyv gK4aUi4ibucUySMFo6FxnwD4ZDuRD9XfCXj375jvMODMlHdG2xfhbuHZwg8WV2kOkk+GXliwdtj2a qPR0dqropEc06cHLUdNEF3NBc80GFIpqEofn913MXqhCVZK9oagfpPasElekuPmjgGSIGKDN+tmz6 B+MDdq4AgacU9mwi/HIMBkeOvjDvofNk3SIz+KhEmUaKod9Aza0bNFTaGD4rYqtNNRiN2leAfvmXU XAvG/Lqz3xl7Ig5AkXWcQJQE24zAxn3uQXJDbRAB8XRFkabiSyHSHAuxzv+fokKtVYzRVWbdYvIoG Gnv1NZXQ==;
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 1wAbhw-003eKr-1y for tls@ietf.org; Thu, 09 Apr 2026 00:49:16 +0200
Received: from [10.12.5.228] (141.76.13.165) 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; Thu, 9 Apr 2026 00:49:11 +0200
Message-ID: <0c51eec9-4446-4cf6-b07a-4481c68d2216@tu-dresden.de>
Date: Thu, 09 Apr 2026 00:49:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: tls@ietf.org
References: <20260408194014.928705.qmail@cr.yp.to>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <20260408194014.928705.qmail@cr.yp.to>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms050309030202030903020004"
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: mailout7.zih.tu-dresden.de
Message-ID-Hash: VO57MRXZ2UWSWFZ5L2DHHMS6DDRW5OA5
X-Message-ID-Hash: VO57MRXZ2UWSWFZ5L2DHHMS6DDRW5OA5
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: RFCs on weakened crypto are not fixed by warnings
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/MKf0ULI0w-gA4jPShTFNpzaSrU0>
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 D. J. Bernstein,
one technical concern first, and then two non-technical ones:
At the end of your 5th last para, you make a very strong claim about
best estimates. Please provide a technical justification of your claim
or provide an authentic reference for that claim. I am asking because to
my knowledge, the /formal/ (vs. /cryptographic/computational/) analyses
consider that /all/ ECC keys are leaked on the advent of CRQC and
essentially model it as a switch to leak all ECC keys. It may be a
simplifying assumption for /formal/ analysis that folks have used but
that seems to be the state-of-the-art in the /formal/ world. I
understand you are a cryptographer and I would like to understand your
reasoning.
---
I think a couple of your technical points are good and I would like to
understand them but your notices make it quite difficult to have a
technical discussion. I have to count the paragraphs and any interested
reader trying to understand have to count it too, and then read that
para and then come back. It seems like an additional burden. Please
consider removing them. If it is not possible, please clarify (ideally
binary answer) in simple words the intended legal interpretation of
these notices whether you allow me to quote parts of your messages
/without modification/ to respond to them point-by-point?
---
Since you brought up your counting of votes, I have a different
interpretation. My vote count is:
Proponents: 20
Opponents: 25
In particular, I see the following missing in your list:
* Richard as author of draft-barnes-tls-this-could-have-been-an-email
* Ekr as /strongly supporting/ the above draft and explicitly
advocating it to be applied to draft-ietf-tls-mlkem [0]
* Toerless Eckert [1] (he even created two issues in repo)
I may have misunderstood their intention but that is how I interpret it.
Several folks (including myself) recorded their objection to anonymous
inputs (see the thread [2]). So I didn't count the anonymous "TLS
participant" as proponent.
Moreover, your blog is only quoting my first email, which was a
non-technical starting point for discussion, which is not representative
of all of my concerns. I have given substantial technical feedback and
raised several technical concerns in the follow-up discussion based on
the modeling and research that I was doing during WGLC.
Best regards,
-Usama
[0] https://mailarchive.ietf.org/arch/msg/tls/vIGryOB0TU_vD81HUUxXQUNdnN0/
[1] https://mailarchive.ietf.org/arch/msg/tls/nKo0pO7R3zJr-sjUyNdvIB1FKas/
[2] https://mailarchive.ietf.org/arch/msg/tls/YZT5IzoumhTt3C53lQR2WOZNvBU/
- [TLS] RFCs on weakened crypto are not fixed by wa… D. J. Bernstein
- [TLS] Re: RFCs on weakened crypto are not fixed b… Viktor Dukhovni
- [TLS] Re: RFCs on weakened crypto are not fixed b… D. J. Bernstein
- [TLS] Re: RFCs on weakened crypto are not fixed b… Viktor Dukhovni
- [TLS] Re: RFCs on weakened crypto are not fixed b… Muhammad Usama Sardar
- [TLS] Re: RFCs on weakened crypto are not fixed b… Peter Gutmann
- [TLS] Re: RFCs on weakened crypto are not fixed b… Bas Westerbaan
- [TLS] Re: RFCs on weakened crypto are not fixed b… Peter Gutmann