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?
Could you clarify what exactly "that" refers to: the last one (new message) or all three above?When that happens, such changes are reflected in the handshake transcript.
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.
Ours used to be like that.
Just to be sure, did you mean BoringSSL?
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?
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: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.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.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?
-Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
