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

Nick Hilliard <nick@foobar.org> Tue, 19 May 2026 21:17 UTC

Return-Path: <nick@foobar.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 C1F33F10DDC1 for <last-call@mail2.ietf.org>; Tue, 19 May 2026 14:17:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779225451; bh=PqrDzLYRpx7Cu6Ok5KgMwOQ+5/XbXrgKcskx6T1iHDg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=pwLFgFeDuzdfAHcSHF49qHLNkpxGYi3htymNOcuEBrrVA8WIMQqLidNkj+V+OBqLo HgCGIq/jCz+bln4lXbwvXUeN+V/AnztNc09Tk2lPPeaJq5PSan/q/ZyGk3NEqcX56w WV9xCxvwNOSk5dlic7YTK+HQJBrp/h6V5EnMtTFU=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -5.824
X-Spam-Level:
X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.624, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 tR3-yZztc7um for <last-call@mail2.ietf.org>; Tue, 19 May 2026 14:17:28 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 46A99F10DC29 for <last-call@ietf.org>; Tue, 19 May 2026 14:17:03 -0700 (PDT)
Received: from Mac.localdomain (unknown [IPv6:2a01:ac:1003:5300:68c5:f708:17d0:c416]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netability.ie (Postfix) with ESMTPSA id EC4389CCF0; Tue, 19 May 2026 22:16:55 +0100 (IST)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <dc5e3bdf-da72-4a27-91e3-beecf67dd770@gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <6777c818-3955-0891-e2a2-548089362b42@foobar.org>
Date: Tue, 19 May 2026 22:16:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 26.4; rv:52.0) Gecko/20100101 PostboxApp/7.0.65
MIME-Version: 1.0
In-Reply-To: <dc5e3bdf-da72-4a27-91e3-beecf67dd770@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID-Hash: UFQUAEDW762K3EGILUJJJJERD3IKQLKL
X-Message-ID-Hash: UFQUAEDW762K3EGILUJJJJERD3IKQLKL
X-MailFrom: nick@foobar.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
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/mNqIHumBiO2kJMfh7-MBWlVS3xg>
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>

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.	

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.

In the IETF, we can bleat all we want about how monumentally foolish 
this chain of consequence might be, but this is largely how things work.

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.

Nick

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