[TLS] Re: Ambiguity of TLS Certificate Compression (RFC 8879)

[Muhammad Usama Sardar <[e-mail]>]

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.

 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?
> 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?
> 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:
>
>    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.
> 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