IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Wed, 20 May 2026 00:07 UTC

Return-Path: <paul@nohats.ca>
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 ADAC8F12B7F2 for <last-call@mail2.ietf.org>; Tue, 19 May 2026 17:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779235642; bh=ca20TwHizM+BjeNvMyGwWlnNXTjPz4JW2Aqjgp84q+I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=aWtM0C2zM0AsP9zGFA6iIGTIEFRTcdb+2j/gqOo8ydbyfRjbi3Xk+NPbTPskoyeqM lvce9ODKmZZfJWd0/mdnhnFhBi78U7qE5wCcgc2FaLTuCnGNNuXfkSrFELa0klSOM/ t3BS0opj7Ll7v+4ZDf6kSObMkuCdliqs+1UzBdnI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_LOW=-0.7, 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=nohats.ca
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 INdziJpl_NWp for <last-call@mail2.ietf.org>; Tue, 19 May 2026 17:07:22 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 12BBEF12B7ED for <last-call@ietf.org>; Tue, 19 May 2026 17:07:21 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4gKsKt2mSbzFTg; Wed, 20 May 2026 02:07:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1779235634; bh=H58pq30xJxgda1jvxYTpK1Rp4tEH5oWD44//h3Nh40E=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=k4IlGZWWG4uYmu8uyWO6wYZV2dlyivc/UaOTAsWrW/LHpLJ8JQUw8Al3ZXTssFb+M ta5s8z9Jhva+K4lIGwHF6x6aFD+J9mrRXuR9/uJFb0nyErm4PBuOtkr9rhf+jeGFnJ ovriLBn8Zt7TvHxx9Jv4o9R9OhKtDbqGxOINY+K4=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id kgxnZzsNLViq; Wed, 20 May 2026 02:07:13 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 May 2026 02:07:13 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 48B9318F446B; Tue, 19 May 2026 20:07:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 452D518F446A; Tue, 19 May 2026 20:07:12 -0400 (EDT)
Date: Tue, 19 May 2026 20:07:12 -0400
From: Paul Wouters <paul@nohats.ca>
To: Nick Hilliard <nick@foobar.org>
In-Reply-To: <6777c818-3955-0891-e2a2-548089362b42@foobar.org>
Message-ID: <8b89fbaf-8690-97a9-7e1c-42b3e18d1e18@nohats.ca>
References: <dc5e3bdf-da72-4a27-91e3-beecf67dd770@gmail.com> <6777c818-3955-0891-e2a2-548089362b42@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-ID-Hash: P46Q75VHAL46XJO3RCXBMT7OSJL5EOP2
X-Message-ID-Hash: P46Q75VHAL46XJO3RCXBMT7OSJL5EOP2
X-MailFrom: paul@nohats.ca
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
CC: last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Last-Call] 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/9Gm9kfvkJCBL_8KQc1743x6-FDo>
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 Tue, 19 May 2026, Nick Hilliard wrote:

> Brian E Carpenter wrote on 19/05/2026 22:03:
>>  I am no expert on the computational cost of cryptanalysis but I think that
>>  the IETF is ethically obliged to warn the readers of our output about
>>  potential risks. RFC 3552 (BCP 72) requires us to document risks. This
>>  doesn't mean we shouldn't document non-hybrid solutions but neither should
>>  we conceal the risks.
>
> this underplays the impact of publication via the rfc series, regardless of 
> track, i.e. whether it's bcp, standards track or informational. Whether the 
> IETF likes it or not, if a non-hybrid pq cipher is published as an 
> informational rfc, it will cause vendors to implement it, even if for no 
> other reason than blind rfc "compliance". I.e. the vendors will tell you that 
> this happens because customers demand compliance with RFC X on the basis that 
> if it wasn't considered to be recommended practice by the IETF, they wouldn't 
> have published the algo as an RFC.

I tried, via draft-pwouters-crypto-current-practices, to try and get to
a situation where algorithms wouldn't get an RFC, but just a code point.
Everyone with a pure/hybrid algorithm wanted their RFC, so it got no
consensus. Then the first hybrid algorithms got their RFCs. To me it
would be weird for those at the head of the line to now say no one
behind them can get an RFC. The ship has sailed.

Additionally, people explains that many organisations (SDO and
otherwise) and vendors put a minimum bar on new standards to support via
the existence of an RFC. The IETF should not misuse this knowledge to
play the internet protocol police. We should, as we always do, faciliate
interoperability and RECOMMEND.

Note that in the far future, one which contains quantum computers breaking
classic algorithms instantly, we are looking at shedding the old then
useless classic algorithms, and go to pure post-quantum algorithms. So
the discussion really is about postponing assigning these RFCs or
assigning them now. Assigning them now has the advantage that whoever
wants to can already experiment or deploy these pure algorithms.

As long as we do not make pure algorithms MTI now, I see no problem with
specifying secure pure post-quantum algorithms in RFCs.

> If it's implemented in vendor crypto implementations, it will be used in 
> production, regardless of whether the rfc contains advice about the risks of 
> using this in production.

There are some big groups that want to use them now (FIPS, 3GPP), and
I don't think the IETF should be the crypto police here. Especially
because both camps here are large, which really leads to a conclusion
that we should specify things so those who want to, can interop, and
let the market and regulation handle who should/may/must or NOT, use
any algorithms.

The IETF, via the IANA registries, lists various algorithms at the level
that the IETF thinks these are RECOMMENDED. People can take or leave
this advise. The IETF doesn't underspecify things to force its opinion.

> The safer long term option would be for the IETF to decline to publish 
> non-hybrid pq algos. For this reason, I do not support publication.

If the non-hybrids were unsafe, I would agree. But let's not forget that
these algorithms are not unsafe. These are the most researched crypto
algorithms in the last 10 years and these have not been broken.

If you want to bring up the analogue of seatbelts, let me bring up the
fact that we still allow motorcycles on our roads too. I will never
drive one because I don't want to die. But I don't think we need to
forbid motorcycles either just because they have less tires and less
seatbelts. And the seatbelts analogy is wrong because the safer long
term will eventually move away from hybrid to pure (or classic only if
real quantum computers never materialize)

I am in favour of publishing draft-ietf-tls-mldsa.

Lastly, I am disappointed that we are seeing the same discussion on
every hybrid/non-hybrid algorithms, as the content of these discussions
is always the same arguments between the same people. At this point,
these discussions are wasting a lot of time and energy in repetition.


Paul

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