I think PR 1401 is similarly minimal, and is a better starting point than PR 1407. It actually tries to define what those "..."s we use in 8446 even mean. Without scoping that to specifically the "..."s, it's actually just false. It claims the messages are taken from that sequence but, even without extensions, post-handshake auth does something slightly funky. By scoping it to specifically the "..."s, it puts the sequence exactly where we need it.
I intentionally split the PRs up precisely to give a menu of different starting points, depending on how much appetite folks had for changes. If I had meant for it to be a single atomic starting point, I would have uploaded one PR. On Thu, Feb 12, 2026 at 4:43 AM Muhammad Usama Sardar < [email protected]> wrote: > IMHO, we should not be doing surgical operations on RFC8446bis at this > point in time. > > With that spirit, I have proposed a small PR [0], which hopefully does the > job. > > I believe RFC8446bis may only clarify the general interpretation of > messages in transcript hash being as sent or received on the wire, and > future specifications should explicitly specify if they want to have an > interpretation contrary to this. What do you think? > > Feel free to wordsmith PR [0]. It is supposed to be a starting point for > discussion, and not a final proposal. > > Also see one opinion inline: > > > On 11.02.26 21:03, David Benjamin wrote: > > On Wed, Feb 11, 2026 at 1:54 PM David Benjamin <[email protected]> > wrote: > >> On Wed, Feb 11, 2026 at 4:36 AM Eric Rescorla <[email protected]> wrote: >> Argh. This text was of course actually intended to add clarity hence the >> "for concreteness" >> at the front, and yes, the idea certainly was that it's all the messages. >> Given that we are >> currently doing RFC 8446-bis (albeit in AUTH48), this seems like a good >> opportunity to >> improve this text. Do you have any suggestions? >> >> I put together a first pass here. >> https://github.com/tlswg/tls13-spec/pull/1401 >> >> It's not enough to make RFC 8897 unambiguous because Certificate is still >> listed by name elsewhere. It also is not enough to unbreak a hypothetical >> extension that, say, injected a message right after EncryptedExtensions. >> I'll see if I can do something there, but it'll require quite a bit more >> surgery. >> > > While I very much appreciate your detailed PRs, IMHO, the goal should not > be to fully disambiguate RFC 8879 within RFC8446bis. I believe that can be > done as Errata to RFC 8879 to clarify the interpretation there. > > Thanks. > > -Usama > > [0] https://github.com/tlswg/tls13-spec/pull/1407 > > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
