[TLS] Re: RFCs on weakened crypto are not fixed by warnings
"D. J. Bernstein" <djb@cr.yp.to> Wed, 08 April 2026 21:30 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 7FC41D85E2E5 for <tls@mail2.ietf.org>; Wed, 8 Apr 2026 14:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775683831; bh=odszcuM2qUeJk/wQDlIXRoDA3z/NgpMF531pmTgzLYM=; h=Date:From:To:Subject:In-Reply-To; b=F2fT/5JciPH4Zxb3ed+jPAoUsr5bnO38fMzbc9+zHiTz+oxPID4uG3SL3yVp3sL2R d112nrguPLEAWOQSz+mxwW+b2BCuxNHkoAm9jmcjpsd+St0pXyPm+FbEGsctK35K9o /Jx2fM/zSf+wOC42fsUKVbMaLxjpOhoaA3NBOQew=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 vXf42KFusRag for <tls@mail2.ietf.org>; Wed, 8 Apr 2026 14:30:31 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id EED38D85E2DF for <tls@ietf.org>; Wed, 8 Apr 2026 14:30:30 -0700 (PDT)
Received: (qmail 3233074 invoked by uid 1010); 8 Apr 2026 21:30:30 -0000
Received: from unknown (unknown) by unknown with QMTP; 8 Apr 2026 21:30:30 -0000
Received: (qmail 934270 invoked by uid 1000); 8 Apr 2026 21:30:19 -0000
Date: Wed, 08 Apr 2026 21:30:19 -0000
Message-ID: <20260408213019.934268.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <ada2BSdJ5MwIWDWs@chardros.imrryr.org>
Message-ID-Hash: EB5WUAKPRDEL6RHZC733NR5DRTKKH4GX
X-Message-ID-Hash: EB5WUAKPRDEL6RHZC733NR5DRTKKH4GX
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
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/LqG-gHxgRvVPebE3m28D8VT7dN4>
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>
Viktor Dukhovni writes: > I don't agree that not publisheing is "safer" or accomplishes anything > worthwhile. I explained that every WG-issued RFC has a prominent claim of IETF "consensus", and that people will interpret the RFC as IETF endorsement, no matter how many warnings there are inside the RFC. Are you disputing this? Or are you saying that IETF endorsement wouldn't tend to increase usage of non-hybrid PQ? Or are you disputing CECPQ2b as an example of ECC+PQ providing more protection than non-hybrid PQ? RFC 2418 says "conflicts must be resolved by a process of open review and discussion". Blanket statements of disagreement aren't engaging in discussion. We should be trying to understand and resolve the disputes. > All that not publishing will do is to move the action elsewhere, where > the caveats are more likely to be neglected. My understanding of your argument here---please correct me if I've misunderstood---is as follows: people saying (e.g.) "Don't use this" shouldn't be opposing publication as an RFC, but instead should be supporting publication as an RFC as an opportunity to include a "Don't use this" warning inside that RFC. But publishing a new problematic RFC along with a "Don't use this" warning is strictly worse than rejecting the RFC and publishing a separate "Don't use this" document, just like previous IETF documents deprecating various other problematic cryptographic choices. Of course, publishing the separate "Don't use this" document would require WG consensus on "Don't use this". But including "Don't use this" in the spec at issue would _also_ require WG consensus on "Don't use this". If, hypothetically, there's WG consensus on "Don't use this", then the WG can and should say so as a separate deprecation document. Your argument doesn't claim any benefit compared to that. If, on the other hand, the consensus doesn't exist, then the supposed benefit that your argument is referring to, the benefit of the WG saying "Don't use this", also doesn't exist. Non-consensual statements can't be issued by the WG. ---D. J. Bernstein ===== NOTICES ===== This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. (That sentence is the official language from IETF's "Legend Instructions" for the situation that "the Contributor does not wish to allow modifications nor to allow publication as an RFC". I'm fine with redistribution of copies of this document; the issue is with modification. Legend language also appears in, e.g., RFC 5831. For further background on the relevant IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)
- [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