[TLS] Re: Tommy Jensen's Discuss on draft-ietf-tls-mldsa-04: (with DISCUSS and COMMENT)

Jack Grigg <ietf@jackgrigg.com> Thu, 02 July 2026 15:44 UTC

Return-Path: <me@jackgrigg.com>
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 6A59210CAF02A for <tls@mail2.ietf.org>; Thu, 2 Jul 2026 08:44:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783007052; bh=KJzjC1HH/2Haigzs5b7Y26MsjRPxDppe+iT7tTeK9oQ=; h=References:In-Reply-To:Reply-To:From:Date:Subject:To:Cc; b=kKCNYm2T4oBy/pvJPV1/vWKYNH3N8WfJv+OSwVMDlJtNDbXsBKjQAfT3egxuBYXEd V9raXT25ihTZA64e4L1iixeg3OHrA38Dg68Tzyee7T9mGaQXW11r++bJTyBDbTeFOQ n7a4D2Lbv6I7i3aewWFh6xNU17mwp8uS1JxFFG50=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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
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 AZmvssM9o6PC for <tls@mail2.ietf.org>; Thu, 2 Jul 2026 08:44:11 -0700 (PDT)
Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 35C6410CAE8B2 for <tls@ietf.org>; Thu, 2 Jul 2026 08:42:32 -0700 (PDT)
Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-c125bcfd9a1so322043266b.1 for <tls@ietf.org>; Thu, 02 Jul 2026 08:42:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1783006951; cv=none; d=google.com; s=arc-20260327; b=NhHgfg9qFe/JUyyvwRAgntjc1vDEQ3/FabHjj8HQ7j3EHu+seOTteJnM5TQRm09eBM 9PeqAzaQy7a2DlFAAwnlqkvrig6idLqeAbbmd0sqYlwsmxCRnyFDq6XY4MqnKWTz2GjD uVf6Mht/BDlS5BqFD9Stz4v3WuuPs6twU87vDOufodj6wCBuKRhmrnlxroTbfFXQyMgv F44uTlpIdknIWneUhIZWCd2tCDGvkh7ZSK28QNrna3Stfy0yqA6EDaQbk3GlgUA0Zkl0 7e2YhJfqURpi/bc5kjghFO9caoiunsUQEJIEctALq6P+mQckpZ72Rti5GngY0nAGIN5K gpCg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version; bh=cWx2thUwSudJBM7hw0/ojvB3L5CIksr1y1ixoOdW52U=; fh=N71rwmkgTp7YlSrfziGkubOln/yvEOqaA7/UKk1iKSA=; b=dVioc180+Dsl78N+uv9KAeLU8QMU3wcnoLQYwHSIoZTbCJ1p5eIAFXsosoLjn50otn /g03+xDIec3TBpGj9cMzxZzJmP08DGlbwJ59/azFi21kiHVxUOSHx0MV/wit/i8xCfls wyssk5FVOzdLh3vy9O5cibK7zaANILO0vzUGnmF8KaAEzU5bMQDnJZcyKCKEbXixhd1J cxn8kfIeAz8khal1AL0hwG+tFca0QbUz4v00QuTz2bNqg+bvr94Bff5kDv0llpJ6P2PM yiTetNi/1dlre19eOvkNo6gU5Mh5SnOBUpwnELCwrGdo6nQq6W7Ffq/5G5bczPXZyM+M Riaw==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783006951; x=1783611751; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cWx2thUwSudJBM7hw0/ojvB3L5CIksr1y1ixoOdW52U=; b=KWZUqxZlUsGpY7HLsJbuOnFclLMMrWtBsM6A80FBlLoBWoyl4GtDTqZyVKz5qeyEHo v4aWgCgGqRWv1cyKNfhA890I3TnOvvhXT0J/tJC1JuhGIJRV3T/pP9DSYPPxZAcwRwKy v6X4IeFtLTElRv0pg1ew8rofs+gB+hJz66N9DzgDaoUO4mBO+ugRYF73BmsG2hprdDvf Y9ErNQpJUDo3aLL0TOfB8XoK3EYVXH5dRrjaN5/aOdIqHdxdCU8pXCgksG0zIOLN3Vx9 CecnHxdyh3QNM3dIh+IxGHAAELptvqj+M6MVkjDpn5RNJu1c8VB7tRl19fGBg4E7455E 7aPA==
X-Forwarded-Encrypted: i=1; AHgh+Rq2vTOX/+cVokgQ9Vxb6D7jWZpRsBVrp3n5YhTvhmniP1TE/4L6768zbttLMNsYoKDv4e4=@ietf.org
X-Gm-Message-State: AOJu0YxD0Bjrx1DEQxHDpMGzCDNvQ/wMIsqGdhYMhpUG9favqLBDFUCG RCIbwTkzfGDyX6OZlw7NHApOrGPpNlKgc9pmIrACq7t5jr9wkTnTOi/wZCCQwQb5m733bkmOMFb URGncpV/Iv9RBnMcV+g6BOqV96AAvEsDkmP5Fs9LO3g==
X-Gm-Gg: AfdE7clCD7E4jE+FxUhq4aphV3MJ+S2n8ZMRa9UaFeGs1U19gKrP7gNnNUCHpeOBaTs FoaX2EWzLd7NYpgblbmutIg5jSZUwMkNfBetSoELQMx88HF+JJuGUSDgO201QB2SubVvhzn16Wn RDeoO62R01iBlPOt3tPmK7VOfo3rb56Hx92IhaIu2SlWg33egxipRoMkq81qOk8/33HFaTnKwOW mlP7VM9eP2BLftCygNIUSO8Y5cynrf4orZS44GxEo0+7vARJohQVjCiknC/BXPMycw7cWZr0A==
X-Received: by 2002:a17:906:4796:b0:bec:18d5:ddf8 with SMTP id a640c23a62f3a-c12aa1419e1mr330282866b.33.1783006951052; Thu, 02 Jul 2026 08:42:31 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR17MB40315CB603D672A04D8CBE36CDF52@MN2PR17MB4031.namprd17.prod.outlook.com> <CAMjbhoWUMYeTvhLjR0yDTF7Gw+CMpTcjdAyojkkyBw11SnK71g@mail.gmail.com> <178296900323.2559760.5279960420005540282@dt-datatracker-f9b87776f-8pmmg> <DB9PR07MB88215412994E7A6EF188CAFF89F52@DB9PR07MB8821.eurprd07.prod.outlook.com> <CABDV=UP=+VZ=U81nR1K3m6gLOanrnxg=8Ykv6ohdVJwB_+PGMg@mail.gmail.com> <2042d7c6-71b2-4307-acdf-20f9a344f8ea@edison>
In-Reply-To: <2042d7c6-71b2-4307-acdf-20f9a344f8ea@edison>
From: Jack Grigg <ietf@jackgrigg.com>
Date: Thu, 02 Jul 2026 16:42:19 +0100
X-Gm-Features: AVVi8CfXOMG4cGz_1rkR0VENDeJIV_8JlH2RRc7U5cr5NIV4PtyjaMpL0Kycz1c
Message-ID: <CAPC=aNU4-H57D6UfOcvY1NBmJTa8aT5=FWVU9jste7st6E8xZA@mail.gmail.com>
To: "tojens.ietf" <tojens.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f3243e0655a2a7af"
Message-ID-Hash: BJSANKZ3UH5BS7MRQRF3THK4SVPOFHFU
X-Message-ID-Hash: BJSANKZ3UH5BS7MRQRF3THK4SVPOFHFU
X-MailFrom: me@jackgrigg.com
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
CC: The IESG <iesg@ietf.org>, draft-ietf-tls-mldsa <draft-ietf-tls-mldsa@ietf.org>, tls-chairs <tls-chairs@ietf.org>, tls <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: ietf@jackgrigg.com
Subject: [TLS] Re: Tommy Jensen's Discuss on draft-ietf-tls-mldsa-04: (with DISCUSS and COMMENT)
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/KBR7ppOixHmctsPQPB2rFkZrCDA>
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>

On Thu, Jul 2, 2026 at 4:11 PM tojens.ietf <tojens.ietf@gmail.com> wrote:

> To your specific point about =N being the default: that makes sense to me
> as an IETF process, but I'm not convinced this is so obvious to someone
> reading the registry, especially the nuance about pre and post 9847 values
> having different implications.
>

I see this as a failure of the registry text itself not being
sufficiently clear. The current IANA TLS registry page [0] has this wording
at the start of every table with a Recommended column:

> Note:
> If the "Recommended" column is set to "N", it does not necessarily
> mean that it is flawed; rather, it indicates that the item either
> has not been through the IETF consensus process, has limited
> applicability, or is intended only for specific use cases. If the
> "Recommended" column is set to "D," the item is discouraged and
> SHOULD NOT or MUST NOT be used, depending upon the situation;
> consult the item's references for clarity.

The second sentence is adapted from RFC 9847 Section 3:

> D: Indicates that the item is discouraged. This marking could be
> used to identify mechanisms that might result in problems if they
> are used, such as a weak cryptographic algorithm or a mechanism
> that might cause interoperability problems in deployment. When
> marking a registry entry as "D", either the "Reference" or the
> "Comment" column MUST include sufficient information to determine
> why the marking has been applied. Implementers and users SHOULD
> consult the linked references associated with the item to
> determine the conditions under which the item SHOULD NOT or MUST
> NOT be used.

However, the first sentence was clearly left at its original adaption from
RFC 8447 Section 5 [1] (which added the column in the first place):

> If an item is not marked as "Recommended" (i.e., "N"), it does not
> necessarily mean that it is flawed; rather, it indicates that the
> item either has not been through the IETF consensus process, has
> limited applicability, or is intended only for specific use cases.

If we compare this to the updated definition in RFC 9847 Section 3 [2]:

> N: Indicates that the item has not been evaluated by the IETF and
> that the IETF has made no statement about the suitability of the
> associated mechanism. This does not necessarily mean that the
> mechanism is flawed, only that no consensus exists. The IETF might
> have consensus to leave an item marked as "N" on the basis of the
> item having limited applicability or usage constraints.
>
> [...] Any item not otherwise specified is set to "N". [...]

we see that the IANA registry page is missing the additional context of
"made no statement", as well as the original context (which this preserved)
from RFC 8447 about N being the default (which described adding a
Recommended parameter as a Standards Action, and "not marked as
Recommended" as the non-Standards Action default state). The IANA registry
*does* separately say for each table that setting Recommended = N is only
Specification Required (vs Standards Action or IESG Approval for all other
transitions), but doing so separately from the context Note doesn't make
the intent from either RFC 8447 or 9847 particularly clear.

Interestingly, this choice of wording was made in RFC 9847 itself [3],
which strongly implies the intention of that RFC was to *add* the D state,
not to *change* the meaning of the N state (at most some state space from N
is carved off into D, but otherwise N has always been the default).

Cheers,
Jack

[0] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[1] https://datatracker.ietf.org/doc/html/rfc8447#section-5
[2]
https://datatracker.ietf.org/doc/html/rfc9847#name-updating-recommended-column
[3] https://datatracker.ietf.org/doc/html/rfc9847#name-recommended-note