In DTLS 1.2, we do this funny thing where, rather than using the type + length TLS Handshake message header, the transcript uses the longer DTLS header and pretends it was a single fragment:
https://www.rfc-editor.org/rfc/rfc6347.html#section-4.2.6
Although we use the transcript in a lot more places now, so perhaps that should be restructured into section about the Transcript Hash. That also gives a good place to talk about...
As an exception to this general rule, when the server responds to a
ClientHello with a HelloRetryRequest, the value of ClientHello1 is
replaced with a special synthetic handshake message of handshake type
"message_hash" containing Hash(ClientHello1). I.e.,
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash || /* Handshake type */
00 00 Hash.length || /* Handshake message length (bytes) */
Hash(ClientHello1) || /* Hash of ClientHello1 */
HelloRetryRequest || ... || Mn)
I don't see any text in DTLS 1.3 which overrides this, but this text is awkward for DTLS 1.3. Do you follow the implication of the CertificateVerify/Finished text and use the longer DTLS header, or do you follow the formula and use the TLS header, switching back to the DTLS header afterwards? We should probably pick one and specify it.
(As an aside, this transcript difference means that DTLS and TLS transcripts are not obviously separable. So anything which uses the transcript must use separate labels between the two, which is a bit annoying given things like ECH invent new uses of the transcript. Though switch DTLS to the TLS construction is probably too late now, and will be differently obnoxious because DTLS 1.2 still requires the old one.)
In DTLS 1.2, we do this funny thing where, rather than using the type + length TLS Handshake message header, the transcript uses the longer DTLS header and pretends it was a single fragment: https://www.rfc-editor.org/rfc/rfc6347.html#section-4.2.6
DTLS 1.3 preserves this text, so I assume the intent is to keep doing this. https://tlswg.org/dtls13-spec/draft-ietf-tls-dtls13.html#name-certificateverify-and-finis
Although we use the transcript in a lot more places now, so perhaps that should be restructured into section about the Transcript Hash. That also gives a good place to talk about...
RFC8446 describes the message_hash machinery as follows: https://www.rfc-editor.org/rfc/rfc8446.html#section-4.4.1
I don't see any text in DTLS 1.3 which overrides this, but this text is awkward for DTLS 1.3. Do you follow the implication of the CertificateVerify/Finished text and use the longer DTLS header, or do you follow the formula and use the TLS header, switching back to the DTLS header afterwards? We should probably pick one and specify it.
(As an aside, this transcript difference means that DTLS and TLS transcripts are not obviously separable. So anything which uses the transcript must use separate labels between the two, which is a bit annoying given things like ECH invent new uses of the transcript. Though switch DTLS to the TLS construction is probably too late now, and will be differently obnoxious because DTLS 1.2 still requires the old one.)