[TLS] Re: rfc8446bis status

Eric Rescorla <ekr@rtfm.com> Thu, 07 May 2026 00:57 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 66E7FEA3A469 for <tls@mail2.ietf.org>; Wed, 6 May 2026 17:57:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778115428; bh=GGGOd++UPMXP5ZGUZHS/9y4gIZzg9G1i8NW1Z2ubCYc=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Qb5IomlItUm+mJgD8qwJlC9BTnsEtU3y7/ZqbXe76nl5Qw2NAcx81DRVRV+gXCGQR ZqjFDKuHDsWiLHW7cwsFnHroovx4YzsZxXnzAeoheSJkmKMhMsx05LwF7m8aCaurF3 WYDDjHhKKT+SpFraFatJR3ZxyG/wjri7BHQrw3jQ=
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.20251104.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 6OQ78-QWNZ6f for <tls@mail2.ietf.org>; Wed, 6 May 2026 17:57:04 -0700 (PDT)
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (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 D99A2EA3A3B3 for <tls@ietf.org>; Wed, 6 May 2026 17:56:48 -0700 (PDT)
Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-7bd5e373d07so2418717b3.2 for <tls@ietf.org>; Wed, 06 May 2026 17:56:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1778115408; cv=none; d=google.com; s=arc-20240605; b=gRdsfxm2G0AqBBiCrvI8wzDiqyReWB5xhpnlSXgeo18/pSd85Qaf+A7IUN/FyokMEt 8Ja1R8K+0Qobh+F7uXysM/UJD9IwQo2vHsoCFkFUbdV4qOdEK2MMxr5QnKotN37XWCZs DrHdzm8S5fc1LBwheV2m316Bg/MfYba+0LXoaPEuU5YJuEhgCFXTKB+Y09dmreMWdj9W uIff4bDq+wZwsNQB/TKeybK5lrv5PxgU7GniPYVw45KA6PijRX+6zo+xUlyHDQ3AW4hi a1mbtsnyCpc6XnNwQCqOQ3g88GhxBrmtjiqEZD4OnnBJ4V9EDFX1/FX1XJ0i9esnOH6C j6Jw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Q0EVkjlQ4CpJ0wKC3x6b9HGbcZL6OWtKjqU386w68cs=; fh=l2QGesb47ehZP4dfEQmHXEQask3poI2KuypvPluhPNk=; b=RaSLMvahkFDtlGZGO5APDNjQG5B97Gizv7hznoIWyKHTGn5QJ911qdgXjhSfIz0P4a WOupInzEljeBorel7XqEUqhytsnyX+rrV3SwWmXsjeEd8SDNeycbiNldpWnqGidKsTpM S/Kc/5cXD0f8ToeRTH5BThPpVam6Ul/l2Knr8bcva52sUxWSTQYGHlBnZdeZWqdlVVWz EQuI9bcSbDSEK0W1MBTxYofmVAlnL4zFO6LQkKh55BLJCYrPOCWLW32TQ1cbSjeF0F6B IR0Y9TxwITpLVvazashyLVtIsMpp18kHMGPcv7aHc2FU5n7zGGutLH8RcB0c4McFd6va LxhQ==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20251104.gappssmtp.com; s=20251104; t=1778115408; x=1778720208; 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=Q0EVkjlQ4CpJ0wKC3x6b9HGbcZL6OWtKjqU386w68cs=; b=VpZmxM2ZsN2pUkRLCuWBNQ05YgEaqvZogyN1xOwGVGEcDvjAPSLXeIT0XuDyMeNyOA aKduVmMRiYjTnqymqBA4Dd9UrdCmHh9fSJzaWqPp5TtGOxvoUP2mxxWEmbya4HrRQC6e UQA0jwCGAEjeUaNS7JYkSF83vtfnbm1ctHd0enWsWWuLncbmMThEI+R0gZDP5Myj0YXL eRWwL0wFsM2A8WzgXDnz/JfliLTlDJBGauP4TCDpO5nRyTmfDoyytxzUlTOyUqonTbk5 QZo3XioeotCPujbxAywR79L5/V/gKg/IYzq4/6cOKX6QuyXkhT+I5JKdHTg8IsVUTEwu GmHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778115408; x=1778720208; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Q0EVkjlQ4CpJ0wKC3x6b9HGbcZL6OWtKjqU386w68cs=; b=W6JGWLeKDm874jiyExrDFhHIGfzlwtjWCoSHoWCQIHwLSjOwCARFBXyZ8nngrfP/86 gQBIljHPLe9jhRK/J655B6TanJK1bXm7ZkPNRYWWIaQBBRUyd309+F953/YtoeKIx3eA PGYAtic37OawUPoiTwxRLP/mXzwY/+UWSVEQv/IknhTT2xF0h6Ix1hDck8Uq0XSSTBGd pEtBiB50S/Efs9+8Xd/djRk353m6Vaq820NuTyMtd9HFBkJgejpvovcMOn1iyneB+Agq CnKKK/CxoyBotIB9uzxMXvj6pAr+CZmq6T339ZgjMLhLp/if+dZf9RbqUfaqsZEZPKAv 0F8A==
X-Gm-Message-State: AOJu0Yz5g/CQvALrN+mu5CDy/u1ucbbGFB5q5h0YYfW9QfqEL/i2wIGD rMSbNnrIplvnmYTiruxbOG2/FjsuAzSGPyEtWfHIS2HibKFEutnYVQir0dr4v5q4k+EclOOz1RM LKnzsZsVwD6rlMj64iuAlNflLiKinUXCW6DN58CiL3w==
X-Gm-Gg: AeBDietZ/vzuNqQkLN1Qb+AjOqILdKLpDtDK7fX+ZKCo7LKzWlSnQEc0GWlwocqS81h 48SYfghGQmRm9m/ERzgFcE+zwUfR9TD0d2WOcApigKz+91I/OxrRoQcSfEyGVuM/TCswDFmBT1y ZzgV1jcrBQQ0PtIgFynNJtFRXROH/bID4utCH+tMB0ryewfDVjc0hq8zjcD9MXOznITMIg9FTBB SzSfDa5NemTrygfpB1jXatxXuBUe8485R1HEB6imJkY1lvbFAECRjHAumuH8YwfYaWCer2gb3QE OOKd6JLfaLuLfpLTwHUgn9A0N2R8VHUhwCJBZKji8tArcB4gEo9hy0weV4Qrh+OdpyvkpOvMkwF l0gjepfhBJrqty7RtlmB3lYtnSykcfPAn
X-Received: by 2002:a05:690c:e04e:b0:7bf:424:bf4d with SMTP id 00721157ae682-7bf0424ed8bmr9694357b3.2.1778115408250; Wed, 06 May 2026 17:56:48 -0700 (PDT)
MIME-Version: 1.0
References: <AS4PR07MB8825673B27A6CCED92F48E18893E2@AS4PR07MB8825.eurprd07.prod.outlook.com> <CABcZeBPGeG7s5GcCmPW_4xVM7qioFZjkELH04Xjj7F01nxAP3g@mail.gmail.com> <AS4PR07MB8825F75E271907108957EB5F893F2@AS4PR07MB8825.eurprd07.prod.outlook.com>
In-Reply-To: <AS4PR07MB8825F75E271907108957EB5F893F2@AS4PR07MB8825.eurprd07.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 06 May 2026 17:56:12 -0700
X-Gm-Features: AVHnY4Ir3DEsTBzOK24qWxLrq42Bk3uDZKHVjtBVaEBTPrinWKUBRoIqKp4-c-U
Message-ID: <CABcZeBO7fnp8A4XxdndNdX3kfFUWxB_-9dBKSAdgNY6=52DMBA@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000047586306512fc120"
Message-ID-Hash: DEQ7WHO2HULNKTJZTRV4XNI6UVQLI33Y
X-Message-ID-Hash: DEQ7WHO2HULNKTJZTRV4XNI6UVQLI33Y
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: rfc8446bis status
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/-xsTPF-wCNLSxNKbHQAuzBCH4q8>
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 Wed, May 6, 2026 at 3:41 AM John Mattsson <john.mattsson@ericsson.com>
wrote:

> I tried to make an PR fixing the inconsistencies between abstract and
> header:
> - Adding all obsolete drafts from the abstract to the heading
> - fixing that 8422 is not both updated and obsoleted
> - Changed "Negotiated Groups" to "Supported Groups". The term "Negotiated
> Groups"
> is only used once and never again.
>
> https://mailarchive.ietf.org/arch/msg/tls/Raci4Lxm1Tk9IxrCpyQgJHMlXBw/
>
> Eric Rescorla wrote:
> >I'm now trying to recall why we did this. ISTM that given that we are
> >obsoleting 5246 (already done in 8446), we should obsolete all the
> >other specs that only meaningfully apply to 5246. Here's the
> >list:
> >
> > * RFC 5077: Transport Layer Security (TLS) Session Resumption without
> >Server-Side State
> > * RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
> > * RFC 5705: Keying Material Exporters for Transport Layer Security (TLS)
> > * RFC 6066: Transport Layer Security (TLS) Extensions: Extension
> >Definitions
> > * RFC 6961: The Transport Layer Security (TLS) Multiple Certificate
> Status
> >Request Extension
> > * RFC 7627: Transport Layer Security (TLS) Session Hash and Extended
> >Master Secret Extension
> > * RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
> >Layer Security (TLS)
> >   Versions 1.2 and Earlier
>
> Note that 5705, 6066, and 7627 are listed as updated and not obsoleted
>

To be clear, I am saying we should change that.

-Ekr


> Cheers,
> John Preuß Mattsson
>
>
> *From: *Eric Rescorla <ekr@rtfm.com>
> *Date: *Wednesday, 6 May 2026 at 01:30
> *To: *John Mattsson <john.mattsson@ericsson.com>
> *Cc: *tls@ietf.org <tls@ietf.org>
> *Subject: *Re: [TLS] Re: rfc8446bis status
>
>
>
> On Tue, May 5, 2026 at 2:21 AM John Mattsson <john.mattsson@ericsson.com>
> wrote:
>
> Hi,
>
> I looked at  https://tlswg.org/tls13-spec/rfc9846.txt
> and found some things that I think should be fixed in AUTH48.
> I made a PR for the two easy editorial corrections
> https://github.com/tlswg/tls13-spec/pull/1416/changes
>
> Cheers,
> John Preuß Mattsson
>
> ----
>
> The heading and abstract are not aligned.
> - The heading says it only obsoletes 8446, while the abstract says 5077,
> 5246, 6961, 8422, and 8446
> - The heading says 8422 is updates, while the abstract says obsoleted.
>
> "Obsoletes: 8446 (if approved)"
> "Updates: 5705, 6066, 7627, 8422 (if approved)”
>
> "This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs
> 5077, 5246, 6961, 8422, and 8446."
>
>
> I'm now trying to recall why we did this. ISTM that given that we are
> obsoleting 5246 (already done in 8446), we should obsolete all the
> other specs that only meaningfully apply to 5246. Here's the
> list:
>
>  * RFC 5077: Transport Layer Security (TLS) Session Resumption without
> Server-Side State
>  * RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
>  * RFC 5705: Keying Material Exporters for Transport Layer Security (TLS)
>  * RFC 6066: Transport Layer Security (TLS) Extensions: Extension
> Definitions
>  * RFC 6961: The Transport Layer Security (TLS) Multiple Certificate
> Status Request Extension
>  * RFC 7627: Transport Layer Security (TLS) Session Hash and Extended
> Master Secret Extension
>  * RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
> Layer Security (TLS)
>    Versions 1.2 and Earlier
>
> ISTM that this standard applies to all of them, so we should just mark
> them all Obsoletes.
>
>
>
> OLD: record_size_limit [RFC8849]
> NEW: record_size_limit [RFC8449]
>
>
> Fixed in auth48 branch.
>
>
>
> ---
>
> OLD: as described in Section 4.1.4).
> NEW:  as described in Section 4.1.4.
>
>
> Fixed in auth48 branch.
>
>
>
> ---
>
> "A client sending a ClientHello MUST support all parameters advertised in
> it"
>
> Shouldn't this be "MUST support all non-GREASE [RFC8701] parameters"
>
>
> See:
> https://github.com/tlswg/tls13-spec/pull/1421
>
> -Ekr
>
>
>
> ---
>
>
>
>
> *From: *Rob Sayre <sayrer@gmail.com>
> *Date: *Friday, 20 March 2026 at 20:27
> *To: *Eric Rescorla <ekr@rtfm.com>
> *Cc: *TLS@ietf.org <tls@ietf.org>
> *Subject: *[TLS] Re: rfc8446bis status
>
> --
>
>
>
> On Fri, Mar 20, 2026 at 12:21 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Fri, Mar 20, 2026 at 12:19 PM Rob Sayre <sayrer@gmail.com> wrote:
>
> Hi,
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/history/
>
> has been in AUTH48 for 3 months now. What's the holdup?
>
>
> The holdup is that we're working through some last minute issues, such as
> https://github.com/tlswg/tls13-spec/pull/1410
>
>
>
> I need to cite it.
>
>
> Cite 8446.
>
>
>
> Oh I would, but I need to say the equivalent of "master secret".
>
> thanks,
> Rob
>
>