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] > <mailto:[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] <mailto:[email protected]>> >> Date: Wednesday, 6 May 2026 at 01:30 >> To: John Mattsson <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> >> Subject: Re: [TLS] Re: rfc8446bis status >> >> >> >> On Tue, May 5, 2026 at 2:21 AM John Mattsson <[email protected] >> <mailto:[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] <mailto:[email protected]>> >> Date: Friday, 20 March 2026 at 20:27 >> To: Eric Rescorla <[email protected] <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> >> Subject: [TLS] Re: rfc8446bis status >> >> -- >> >> >> >> On Fri, Mar 20, 2026 at 12:21 PM Eric Rescorla <[email protected] >> <mailto:[email protected]>> wrote: >> On Fri, Mar 20, 2026 at 12:19 PM Rob Sayre <[email protected] >> <mailto:[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]
