On Wed, Feb 11, 2026, 09:15 Muhammad Usama Sardar < [email protected]> wrote:
> In formal model, I always take what is actually sent/received by the > endpoints. I suspect additional lemmas will be required for the proofs if > it is not the case. > I think everyone takes this interpretation. Let's not change it. > From a formal analysis perspective, by now, I had all three cases you > mention, i.e.: > > - Extensions to existing messages > - Modification of existing messages > - Addition of new messages > > On 11.02.26 03:18, David Benjamin wrote: > > Like many extensions, RFC 8879 changes the messages that are sent over the > handshake stream, both in contents (new extensions added to ClientHello and > CertificateRequest) > > I like to think of those as extensions to existing messages. > > and in type (CompressedCertificate is sent instead of Certificate). > > I like to think of those as modification of existing messages. > > While it is rare that we change the message types, it's not unheard of. > For example, RFC 6066 introduced the CertificateStatus message. > > I like to think of those as addition of new message. In this case, RFC > 6066 is for TLS 1.2. I don't directly see how this is necessarily relevant > for RFC8446bis. Is there any RFC where a new message was added to TLS 1.3 > handshake? > The one we are talking about right now does this? It replaces a message with a different one. > When that happens, such changes are reflected in the handshake transcript. > > Could you clarify what exactly "that" refers to: the last one (new > message) or all three above? > All of the above. > Indeed some handle the transcript automatically under the handshake layer > and would *only* be able to implement this version. > > I don't quite get that "*only*". Whatever layer it is implemented, it is > still software which -- in principle -- can be changed (hardware can be > changed, too but a bit more costly). This may need some work to > re-architecture (just like you were able to) but I don't think the > reasoning is that they are *not able* to implement the other version. > Yes, I mean that it would be a significant amount of effort and break some core assumptions to implement the other version. It sounds like your formal models are the same. But it does not sound like anyone wants the other version, so this is all fine. > Ours used to be like that. > > Just to be sure, did you mean BoringSSL? > Yes. BoringSSL is derived from an older iteration of OpenSSL. Our common ancestor, handled all the transcripting of input and output messages automatically. Come to think of it, I think we still transcript output messages automatically. It's just input that is hashed in explicitly by the handshake, so that it can be timed with other processing at the right time. (At the time you process, say, CertificateVerify, you need the message not yet transcripted yet.) > And it happens that other TLS handshake mechanisms interact with the > result of that decompression as if they saw a vanilla Certificate message, > but that's all within the handshake proper and about the handshake stream > that we transcribe. > > I couldn't follow what you are trying to say here. In particular, what is > *vanilla > Certificate message*? Neither RFC8446bis nor RFC8879 specifies/uses it. > Where can I find its specification? > Unmodified Certificate message. > 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. > > If you "take literally", I couldn't follow how you came to conclusion > "unless it says otherwise", specially given that the quoted text says " > *always*", independent of whatever the extensions define. > It is always the case that updating documents are allowed to override text in the base document. > That's not what we want, both by how real implementations work, or by the > security goals of the transcript. > > I can't say anything for real implementations but agree for security goals > from a formal analysis perspective. > > But in TLS we're sloppy enough about messages with and without the header > that it's worth being explicit. > > Do the headers contain any security-relevant information? If not, isn't it > intentionally just left over as an implementation choice, rather than being > sloppy? > I think you misunderstand the comment. It is very, very much not implementation choice whether the decompressed message should contain or not contain the header. You cannot interop if you don't agree here. The header is just the four byte message type and message length. In this context, it is not necessary (length carries no information and type is known from context), so it is correct to omit it from the compressed payload and save some bytes. When I say sloppy, I simply mean that our prose is a little sloppy about when we mean a literal Certificate structure, which is just the body without type information, or to receive a message of type HandshakeType.certificate and body a Certificate structure. That's fine because the distinction is usually not meaningful in prose. In this case, it is, and the RFC should have said so explicitly which we meant. David
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
