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: > >> On Tue, Feb 10, 2026 at 6:19 PM David Benjamin <[email protected]> >> wrote: >> >>> But then the problem is the transcript in RFC 8446 is not actually >>> defined in terms of what's actually sent/received over the handshake >>> stream. It is defined in reference to particular messages, albeit with >>> some "..."s in between. It also says this: >>> >>> For concreteness, the transcript hash is always taken from the >>> following sequence of handshake messages, starting at the first >>> ClientHello and including only those messages that were sent: >>> ClientHello, HelloRetryRequest, ClientHello, ServerHello, >>> EncryptedExtensions, server CertificateRequest, server Certificate, >>> server CertificateVerify, server Finished, EndOfEarlyData, client >>> Certificate, client CertificateVerify, client Finished. >>> >>> >>> https://www.rfc-editor.org/rfc/rfc8446#section-4.4.1:~:text=For%20concreteness%2C%20the,CertificateVerify%2C%20client%20Finished >>> . >>> >>> Taken literally, this text would suggest that, if an extension adds or >>> modifies handshake messages, it's not reflected in the transcript, unless >>> it says otherwise. That's not what we want, both by how real >>> implementations work, or by the security goals of the transcript. We >>> *want* message modifications to show up in the transcript by default, >>> but the formal text does not say this. And thus the ambiguity. >>> >> >> 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. > I took a shot at tidying that up here. It's in four separate PRs total because I'm not sure which change(s) would make sense at this point in the process. Figured I'd write it all up and folks can decide what to do. https://github.com/tlswg/tls13-spec/pull/1402 https://github.com/tlswg/tls13-spec/pull/1403 https://github.com/tlswg/tls13-spec/pull/1404 David David > > >> -Ekr >> >> >>> >>> David >>> >>> [*] Actually, this seems to also be a point of ambiguity. The spec says >>> you compress a Certificate, and the Certificate structure indeed does not >>> have the four-byte header. Looking at our implementation, we indeed only >>> compress that portion and not the header. I assume (but haven't checked) >>> that's what other implementations do because we'd probably have heard of an >>> interop issue by now. But in TLS we're sloppy enough about messages with >>> and without the header that it's worth being explicit. >>> >>> On Wed, Feb 4, 2026 at 1:17 AM Nico Williams <[email protected]> >>> wrote: >>> >>>> On Fri, Jan 30, 2026 at 12:46:40PM +0900, Kazu Yamamoto (山本和彦) wrote: >>>> > But RFC 8879 says: >>>> > >>>> > After decompression, the Certificate message MUST be processed as >>>> > if it were encoded without being compressed. >>>> >>>> In my opinion the quoted text is not ambiguous, and no errata is >>>> necessary. >>>> >>>> First, RFC 8879 does not change how TLS 1.3 computes its transcripts. >>>> More on this below. >>>> >>>> Second, the quoted sentence is superfluous and unnecessary. What >>>> "processing" does one do with the Certificate message? One validates >>>> the certificate. But RFC 8879 does not provide a way to validate >>>> compressed certificates apart from decompressing them and then >>>> validating them as usual. And what other validation method could one >>>> design other than decompress then validate as usual? Therefore the >>>> quoted sentence was never necessary: because it's obvious. >>>> >>>> Third, the next sentence in the RFC says: >>>> >>>> [...]. This way, the parsing and >>>> the verification have the same security properties as they would have >>>> in TLS normally. >>>> >>>> but one does use "parsed" messages to compute the TLS handshake >>>> transcript hash. So clearly the first sentence would not be consistent >>>> with any intent to change the way the transcript hash is computed. More >>>> below. >>>> >>>> > I think the following original interpretation is possible for the >>>> > content: >>>> > >>>> > Transcript-Hash(Handshake Context, Certificate) >>>> >>>> RFC 8879 does not change how TLS 1.3 computes its transcripts. Nor >>>> should it. And if it did it would have to be explicit about it. >>>> >>>> The point of the transcript being >>>> >>>> Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn) >>>> >>>> is that M1, M2, .., Mn are the N messages sent / received _as they are >>>> sent or received_ without any alterations. The whole point of the >>>> transcript hash is to _detect alterations_. Therefore no compression of >>>> any part of the handshake should alter the Transcript-Hash() function. >>>> >>>> The handshake transacript is such a critical and core design point of >>>> TLS that, had the Internet-Draft preceding RFC 8879 meant to alter the >>>> Transcript-Hash() function then surely it would never have managed WG >>>> consensus. >>>> >>>> Nico >>>> -- >>>> >>>> _______________________________________________ >>>> 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] >>> >>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
