IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 23 May 2026 08:16 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 B449CF3AE25E; Sat, 23 May 2026 01:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779524203; bh=TMwtOvzw0aBfY4NrF5lU7v5Mz58TWAbYRQuW0Rb/+as=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To; b=wcrpH28n0BucjF4unIYypBlS/X5Zo3MAPemf3SKoPgEE1HZ0EFdw315+BB9e/TDTU x5BcVgRajGuKdELj96naxQ9TfFlOsLCg/4x+NykQr0SSmd9TYg1Xwm6awsWwu5olWX q9mZeDCEk/jPXIwbSKfwT2vCUQvbjE5Z5T+FdRSw=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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, 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] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
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 18AMETnTyYWQ; Sat, 23 May 2026 01:16:42 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9B793F3AE11A; Sat, 23 May 2026 01:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1779524119; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=TMwtOvzw0aBfY4NrF5lU7v5Mz58TWAbYRQuW0Rb/+as=; b=TkdqMsIKuC24LWWQ/dYeljj4YCMF5cgc2j3QVYHm/ft+T/iB10RS/vB9tSI0iJ+r6lDhA /dpeBD6Qel8ACO5VRRGHwdAUSOA18HDW4d4TARVm1jZj6HAe1SW7VJ6ixTi7l1cy2990soH I3PBq1xmLl6YbDBrK9JDniT+oTq0ZDw=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 4C5D493559C; Sat, 23 May 2026 18:15:19 +1000 (AEST)
Date: Sat, 23 May 2026 18:15:19 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: last-call@ietf.org, tls@ietf.org
Message-ID: <ahFiFxrHejySxob4@chardros.imrryr.org>
References: <MN2PR17MB40312B24D1D3016515DD7149CD0F2@MN2PR17MB4031.namprd17.prod.outlook.com> <20260523063634.1526008.qmail@cr.yp.to>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20260523063634.1526008.qmail@cr.yp.to>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: SOSXB3CHC2TR2FSCZAP3GELEEIVWQ2VJ
X-Message-ID-Hash: SOSXB3CHC2TR2FSCZAP3GELEEIVWQ2VJ
X-MailFrom: ietf-dane@dukhovni.org
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
Reply-To: tls@ietf.org
Subject: [Last-Call] Re: [TLS] 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/pz7YUV9ZiMCfCIuYQy4Jo9oH0tI>
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>

On Sat, May 23, 2026 at 06:36:34AM -0000, D. J. Bernstein wrote:

> There were only 37 people stating support (even _after_ vote-packing
> by NSA and its "vendors"), versus 14 people stating objections. 

I don't believe that you're suggesting a plausible NOBUS secret in the
design of ML-DSA, that allows only NSA to break the algorithm even
after the underlying weakness is discovered.

The risk is therefore, that at some point the algorithm can be broken by
*anyone*, not just NSA.  In that case, I see no incentive for NSA to
promote adoption of the algorithm not just by foreign actors, but also
by US entities, including the US government.  If/when such a weakness
inevitably becomes public, much of the damage would have been incurred
by US entities (or in general by more open societies).

In that light, it seems a stretch to suggest that ML-DSA is being
foisted on the industry by NSA as part of their surveillance mission.

Perhaps NSA are just naïvely optimistic in their evaluation of the
ML-DSA algorithm, and foolishly believe it to be strong enough to
protect US (and in particular USG) traffic.  That's certainly a position
you might take, but it is not surprising that many would not find it
very compelling.

Perhaps NSA are largely realists, but their risk evaluation skews much
more strongly towards timely mitigation of classical algorithm failure,
to which they assign a significant probability, much higher than that of
ML-DSA failure.  If the classical component of the hybrid is expected to
fail long before ML-DSA does, there's little value in fielding a hybrid.

In that case, you're arguing that the IETF should adopt a risk profile
that is much more conservative than that of NSA, with less weight
attached to the probability of near-term failure (CrQCs appearing)
of classical algorithms, and more weight attached to the probability
of ML-DSA failure (an algorithm that might yet fall to novel attacks).

If CrQCs take much longer to appear than recent (circa 2029) speculative
timeframes suggest, and in that extended timeframe ML-DSA falls to novel
cryptanalysis, you'd be proved right.  But NSA will then have egg on
their face, not because their subterfuge got unmasked, but because their
security assessment of ML-DSA was faulty.

Bottom line, I think you do your argument a disservice by dragging in
the NSA bogey man as a reason why ML-DSA should not be standardised in
the IETF.  By all means, make a case that your risk profile is the more
prudent one, and/or that there's no consensus risk-profile.

My personal take is that an RFC defining ML-DSA in TLS is a how-to
document, not a whether-to document, and that risk profile choices
should not gate publication.

FWIW, I've been supportive of including security considerations that
make the risk-tradeoff explicit, but with or without such language, also
supportive of publication, because I don't see that any of the Sturm und
Drang will make much difference, other than to the reputation of the
IETF.  The codepoints are assigned, the algorithm is in use, and,
unless/until a significant failure or a much better alternative is found,
the use of ML-DSA will grow (e.g. it is reportedly now in Chrome canary).

-- 
    Viktor.  🇺🇦 Слава Україні!

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