IETF Logo Mail Archive

[Last-Call] Re: [TLS] Re: Re: Re: Re: Re: Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

"D. J. Bernstein" <djb@cr.yp.to> Sat, 23 May 2026 19:07 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: last-call@mail2.ietf.org
Delivered-To: last-call@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CB294F3E58B7 for <last-call@mail2.ietf.org>; Sat, 23 May 2026 12:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779563244; bh=KSSYl6w5Tu0hkztG5YssnONngqZYKD/+tNJiHnW79Is=; h=Date:From:To:Subject:In-Reply-To; b=Ep7thwOQyGr12SDSfDrfZZPxlTZnjTYwoHeFytAFDSmZ/AhdocWRo+j1i+cpEl40H 7XvPefJl2EoxaCEbEJsB5QSEe+L99cE/YWIrAW7Vis0VHuQfRwpjXt/hIy5gIRzgs0 AK8K34MYVY4q8dKXy02xfXC6FOHy4OzfN7NZ4aY8=
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=unavailable 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 KYUr9T7nVcWz for <last-call@mail2.ietf.org>; Sat, 23 May 2026 12:07:23 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id A7D74F3E58AB for <last-call@ietf.org>; Sat, 23 May 2026 12:07:23 -0700 (PDT)
Received: (qmail 553789 invoked by uid 1010); 23 May 2026 19:07:22 -0000
Received: from unknown (unknown) by unknown with QMTP; 23 May 2026 19:07:22 -0000
Received: (qmail 1563654 invoked by uid 1000); 23 May 2026 19:07:09 -0000
Date: Sat, 23 May 2026 19:07:09 -0000
Message-ID: <20260523190709.1563652.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org, last-call@ietf.org
Mail-Followup-To: tls@ietf.org, last-call@ietf.org
In-Reply-To: <ahHtf34Wqy4ITP-A@chardros.imrryr.org>
Message-ID-Hash: 3DJQGU2PKX6LYYFV6BMQVDG2B6AB4XFX
X-Message-ID-Hash: 3DJQGU2PKX6LYYFV6BMQVDG2B6AB4XFX
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; 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: [Last-Call] Re: [TLS] Re: Re: Re: Re: Re: Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC
List-Id: IETF Last Calls <last-call.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/rF7lKNer1sv3fakorfqVjV5w-zs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Owner: <mailto:last-call-owner@ietf.org>
List-Post: <mailto:last-call@ietf.org>
List-Subscribe: <mailto:last-call-join@ietf.org>
List-Unsubscribe: <mailto:last-call-leave@ietf.org>

Viktor Dukhovni writes:
> That sort of argument would I think have carried more weight if
> clearly articulated and adhered to from the outset.

Shortly after NSA and GCHQ posted a series of anti-hybrid arguments, I
posted https://blog.cr.yp.to/20240102-hybrid.html identifying security
flaws and engineering flaws in those arguments. I also linked to that on
the TLS mailing list on 11 January 2024, 6 March 2024, etc., along with
commenting on specific issues. I've also pointed back to this in various
newer postings. I also have a newer chart summarizing the claimed pros
and cons of these specs: https://blog.cr.yp.to/20260221-structure.html

If you think I failed to articulate something clearly or failed to
adhere to something, please quote the text at issue.

> I don't see the strategy so far as likely to win broad support.

14 people filed objections to this non-hybrid-ML-DSA-in-TLS spec (and to
the non-hybrid-ML-KEM-in-TLS spec, which attracted even more objections)
in the TLS WG before the end of the specified WG "last call" period.
That's more than enough to demonstrate how controversial this spec is.
By default, a spec does not move out of the WG; the idea that opponents
need to achieve consensus _against_ the spec gets the burdens backwards.

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

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" is as follows: "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."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

Rationale: I'm fine with redistribution of copies of this document. The
issue is with modification, such as (1) IESG's May 2025 posting of an
IESG-mangled version of an appeal that I had filed and (2) IETF
management selling IETF mailing-list text to AI companies.

v2.46.0 | Report a Bug | By Email | System Status