IETF Logo Mail Archive

[TLS] Re: Last Call: <draft-ietf-tls-rfc8447bis-11.txt> (IANA Registry Updates for TLS and DTLS) to Proposed Standard

Paul Hoffman <phoffman@proper.com> Thu, 13 March 2025 18:59 UTC

Return-Path: <phoffman@proper.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 04C1EAF4B24; Thu, 13 Mar 2025 11:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UwdVgijkaZNA; Thu, 13 Mar 2025 11:59:25 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 060B3AF3AC8; Thu, 13 Mar 2025 11:50:52 -0700 (PDT)
Received: from [10.32.63.113] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 52DIolJQ045331 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Mar 2025 11:50:47 -0700 (MST) (envelope-from phoffman@proper.com)
X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged) claimed to be [10.32.63.113]
From: Paul Hoffman <phoffman@proper.com>
To: last-call@ietf.org
Date: Thu, 13 Mar 2025 11:50:46 -0700
X-Mailer: MailMate (2.0r6222)
Message-ID: <6BB43AEB-CF42-4FE2-998A-DB85B373D464@proper.com>
In-Reply-To: <174184001345.838119.1665635750501653391@dt-datatracker-775fc5cbb8-824tp>
References: <174184001345.838119.1665635750501653391@dt-datatracker-775fc5cbb8-824tp>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: HLZCCER7QAX7ZHXDWSR7NN3XGFLHXRRA
X-Message-ID-Hash: HLZCCER7QAX7ZHXDWSR7NN3XGFLHXRRA
X-MailFrom: phoffman@proper.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: draft-ietf-tls-rfc8447bis@ietf.org, paul.wouters@aiven.io, tls-chairs@ietf.org, tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Last Call: <draft-ietf-tls-rfc8447bis-11.txt> (IANA Registry Updates for TLS and DTLS) to Proposed Standard
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/B_yMX2dkZi_BxLZ0Xphg37PfX9g>
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>

Greetings again. The contents of this draft are fine but definitely incomplete. The draft gives clear language about whether particular cryptographic components are recommended for use in TLS, but no guidance for implementations of what those implementations should do if given a discouraged code point.

If a TLS server negotiates to a cryptographic component labelled "D". what SHOULD / MUST the client do?

If a TLS client only offers D-level components, what SHOULD / MUST the server do?

A program's configuration mechanism SHOULD NOT / MUST NOT allow specifying D-level components?

This draft should either be expanded to say what TLS clients and servers and configuration SHOULD / MUST do with D-level components. If it is too difficult for the TLS WG to agree on specific actions, the draft should at least say that so that the reader knows what to do with these new ratings. Without such wording, the new "D" label becomes useless in practice, which is clearly bad for security and interoperability.

--Paul Hoffman

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