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. 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]
