[TLS] Re: Do we really update RFC 8422 in 8446-bis?

Eric Rescorla <ekr@rtfm.com> Fri, 30 May 2025 16:05 UTC

Return-Path: <ekr@rtfm.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 481452ED2759 for <tls@mail2.ietf.org>; Fri, 30 May 2025 09:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.com
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 FNRM88thP0FQ for <tls@mail2.ietf.org>; Fri, 30 May 2025 09:05:03 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 B6B9E2ED2744 for <tls@ietf.org>; Fri, 30 May 2025 09:05:03 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-e7dcd60c092so1736445276.3 for <tls@ietf.org>; Fri, 30 May 2025 09:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1748621103; x=1749225903; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4sXhjLVec/jxGhrqAYWKsq9XgDZbMk9QEhxN5HZRYM0=; b=gVE5qQlUjtY3rCjs2hajN1mruchV2pE2R/pqV3coaECc9MO6b5LaVOgnlm5sh9MN2+ 1qP5yWR07jwVC2KyQkC2Evx+rP5f/OL/7AGUP+IyBx5/EEmOG2inBvPzFc7Mg+qqp03U AWgc6trxwqHBb1ZMmw9/Xa2UP3tkrkh23ySd3YPjb6gtAbq4uPPh42RK8Rb9bveSDTdT YIgNpy9GO9jhBFlC6+pEp7iQheju8h5iEZTxkQJUgn3rdNyhRGdueeA870VE5ssr+roJ h3QKYUg5QEK7pkhTuNwqirGIGx7UVZuKHYTrsaCzd1Pgd11NoWH5X2C1xV1VFM/Ra4KB E/hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748621103; x=1749225903; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4sXhjLVec/jxGhrqAYWKsq9XgDZbMk9QEhxN5HZRYM0=; b=W/3CPPZv3kMUhGVRb95QNyI2nXxFaUv2DxQdsSQ2yLopR6QzThAUEGvH7WJAIAtWgQ zH5viu8UizGNvI7W7gRhB38ZVT5Dyyz/ZVPFfpu8nCLFAzWULZr90EIJ2UA8HGETtG4K xx8i16/5T/A2eYtco3jcv3MD9xL7AZZWMpiXpJa8YnrpN3huDbkkzxica5n8WEpanRK3 dpykgB9BArFIqCEN3/wNX6lS+tUXhPA9TnxmJuX/BdXbFC1vH1+UGP2J+mIUT/xZ556y n3s84gXis19A2LyijeuRLep+G8Wv+HyzFEq2NgWy558e8HZRWrwouj0IKgd/oF2qNk2z QE1Q==
X-Gm-Message-State: AOJu0YzjAfEGWfvT1qnHcl2eONQa+Sl3+rREfh3DMkDNmCsWiujB1lM2 CwgGwchFJJ+PwDOpY6kCS66YfRWOyXlw/d98Lz+t6JceYYRl3qtngo0S7i0SWbg+3uoI3/PuB8a 9i27aiqeeyxJg8MkC12Bs5WEVuTLQew0Ztlw4ggG+Tg==
X-Gm-Gg: ASbGncsdOfya9NOdsGwfmnusHDUNN3HvM1nGWAU9pre0zwqJYXPIIclSvEadBU5LBmn Fan4+7uyxJ11sFb0SYcsMsAhQFAH1ZamskGOwQY9/SsJBYN9ptpkfWl5azudv07TF8lynGPZCS/ AqT4GXMiWE2vEHvuwJQLieq1ukV7mHyka6veg=
X-Google-Smtp-Source: AGHT+IFkTkkvqAjjQ4qvNSSO/y/qd0yb6NMs+2UJYv38seocFuOxIiSwFtAwptjW5TPOhnVMLZttRoVQCnbF6+HeRnA=
X-Received: by 2002:a05:6902:c13:b0:e7d:6fe3:fc81 with SMTP id 3f1490d57ef6-e7ff611de5dmr3099999276.30.1748621103149; Fri, 30 May 2025 09:05:03 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBM9a90HuTovaPEL3wrx1MUWE0v0-RX12pirBRwRXnw+4g@mail.gmail.com> <IA1PR17MB642172802E4C034F37B3632ECD61A@IA1PR17MB6421.namprd17.prod.outlook.com>
In-Reply-To: <IA1PR17MB642172802E4C034F37B3632ECD61A@IA1PR17MB6421.namprd17.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 30 May 2025 09:04:27 -0700
X-Gm-Features: AX0GCFt8bWcfJgEZEs-thApcIwK_a138tKMEL79L3pOhvI23Y_H9i_bxdpDWgzY
Message-ID: <CABcZeBMVn-ELTG1QwN59uhQWzxAqP09fLgmTbj9VLce+AimGxQ@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary="000000000000b34bfd06365c9359"
Message-ID-Hash: 4GQYRIT4JZL3A6CO737TD4OX2ZQBNS4N
X-Message-ID-Hash: 4GQYRIT4JZL3A6CO737TD4OX2ZQBNS4N
X-MailFrom: ekr@rtfm.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: "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Do we really update RFC 8422 in 8446-bis?
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/XzXKVW1zyxpm-1BhEEhQ6WYh_JE>
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 Fri, May 30, 2025 at 8:57 AM Salz, Rich <rsalz@akamai.com> wrote:

> Based on the opening sentences of 8422:
>
>
>
>    This document describes additions to TLS to support ECC that are
>
>    applicable to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2
>
>    [RFC5246].  The use of ECC in TLS 1.3 is defined in [TLS1.3] and is
>
>    explicitly out of scope for this document.
>
>
>
> It seems that mutually ignoring is best :). I.e., 8446bis doesn’t update
> 8422 except in a strange way because it obsoletes TLS 1..2
>
>
>
> And while I’m here, why does it obsolete 5246 (TLS 1.2) if it “also
> specifies new requirements for TLS 1.2 implementations” ?  So should that
> be updates, not obsoletes 5246?
>

I'm certainly not here to defend the distinctions between Updates and
Obsoletes, etc. But with that said:

1. I think the reasoning here was that TLS 1.3 obsoletes TLS 1.2 in the
sense that 1.2 is now obsolete and we want you to use TLS 1.3.
2. RFC 8446 already obsoleted 5246, so I think that ship has sailed.

The 8422 change is new to RFC 8446bis, so we need to address that now.

-Ekr



>
>