On Wed, Feb 11, 2026 at 01:36:05AM -0800, Eric Rescorla wrote:
> On Tue, Feb 10, 2026 at 6:19 PM David Benjamin <[email protected]>
> wrote:
> >
> > 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?
Option 1:
OLD:
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.
NEW:
For concreteness, the transcript hash is always taken from the
following sequence of handshake messages, as sent or received, with
no local modifications, starting at the first ClientHello and
including all those messages that were sent starting with the first
ClientHello through the client Finished.
Option 2: Remove the "For concreteness paragraph and change the first
paragraph in 4.4.1 like this:
OLD:
Many of the cryptographic computations in TLS make use of a
transcript hash. This value is computed by hashing the concatenation
of each included handshake message, including the handshake message
header carrying the handshake message type and length fields, but not
including record layer headers. I.e.,
NEW:
Many of the cryptographic computations in TLS make use of a
transcript hash. This value is computed by hashing the concatenation
of all handshake messages as sent and received -with no local
modifications- starting with the first ClientHello and ending at the
client Finished, including the handshake message header carrying the
handshake message type and length fields, but not including record
layer headers. I.e.,
IMO option 2 is clearer, and removing a paragraph that becomes redundant
is like removing code that becomes unnecessary: a feature.
Adding BCP14 normative language would be nice.
Nico
--
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
