Upon re-read, I have created a new PR targeting the auth48 branch (main is on pause for now).
It does the following: updates: 5705, 6066 obsoletes: 5077, 5246, 6961, 7627, 8422, 8446 The reasoning is that the obsoletes are TLS 1.2 only (or TLS 1.3). The updated RFCs are still active. https://github.com/tlswg/tls13-spec/pull/1426 -Ekr On Thu, May 7, 2026 at 7:25 AM Sean Turner <[email protected]> wrote: > Since this specification can't both update and obsolete RFC 8422 and > making the abstract and header match makes sense. But, I think the last > paragraph of s1 also needs a sentence that explains how/why RFC 8422 is > obsoleted. Will add this comment to the PR. > > spt > > On May 6, 2026, at 12:56, Eric Rescorla <[email protected]> wrote: > > Thanks for the PR. I'll take it you're in favor of this change. Anyone > else want to weigh in? > > -Ekr > > > > On Wed, May 6, 2026 at 3:41 AM John Mattsson <[email protected]> > 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 >> >> Cheers, >> John Preuß Mattsson >> >> >> *From: *Eric Rescorla <[email protected]> >> *Date: *Wednesday, 6 May 2026 at 01:30 >> *To: *John Mattsson <[email protected]> >> *Cc: *[email protected] <[email protected]> >> *Subject: *Re: [TLS] Re: rfc8446bis status >> >> >> >> On Tue, May 5, 2026 at 2:21 AM John Mattsson <[email protected]> >> 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 <[email protected]> >> *Date: *Friday, 20 March 2026 at 20:27 >> *To: *Eric Rescorla <[email protected]> >> *Cc: *[email protected] <[email protected]> >> *Subject: *[TLS] Re: rfc8446bis status >> >> -- >> >> >> >> On Fri, Mar 20, 2026 at 12:21 PM Eric Rescorla <[email protected]> wrote: >> >> On Fri, Mar 20, 2026 at 12:19 PM Rob Sayre <[email protected]> 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 mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
