[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 > >
- [TLS] Re: rfc8446bis status Eric Rescorla
- [TLS] Re: rfc8446bis status John Mattsson
- [TLS] rfc8446bis status Rob Sayre
- [TLS] Re: rfc8446bis status Rob Sayre
- [TLS] Re: rfc8446bis status John Mattsson
- [TLS] Re: rfc8446bis status Eric Rescorla
- [TLS] Re: rfc8446bis status Eric Rescorla
- [TLS] Re: rfc8446bis status Paul Wouters
- [TLS] Re: rfc8446bis status Salz, Rich
- [TLS] Re: rfc8446bis status Sean Turner
- [TLS] Re: rfc8446bis status Eric Rescorla
- [TLS] Re: rfc8446bis status Eric Rescorla