Rewrite CertificateVerify and Finished transcript hash definitions

[davidben]

(This is a standalone PR because GitHub is bad at stacked PRs, but you probably want to look at #1401 first.)

Rather than trying to define in terms of a funky Handshake Context and then a set of messages that are appended throughout, define this the way it is actually implemented: you stop the transcript just before the message you are working on.

One cloud darkens this simple description: post-handshake authentication acts on a funny transcript where the main transcript is forked off and then we get extra messages appended to it.

[martinthomson]

Lots of changes, but I don't see a major problem.

[martinthomson]

Is "Previous" a good name? "Last" might be better. Or "end_of_transcript" or "last_in_transcript" (see, different casing to indicate it's a variable). The title case word is too much like a real Handshake message.

[davidben]

"Last" is a bit ambiguous between "the final message" vs "the message before the current one". In this context, it seemed good to be precise. Good call about the title case. Will fix.

[ekr]

This is an interesting suggestion and it might have been a better way to write things, but I don't think we should make it now, for two reasons:

1. RFC 9261 (Exported Authenticators) explicitly uses the concept of Handshake Context (in fact, I think this may have been why we added it), so we'd be breaking that.
2. It's just a big change at this point in the process, so it's an opportunity to break things.

I think the most expedient thing to do is to take #1401, #1402, and #1404 but not #1403. This addresses the ambiguity while minimizing changes.

@davidben I'm happy to take care of that, but I wanted to see if people wanted to argue differently before I made those changes.

[davidben]

RFC 9261 (Exported Authenticators) explicitly uses the concept of Handshake Context (in fact, I think this may have been why we added it), so we'd be breaking that.

I think that one is fine? From a brief skim, RFC 9261 already redefines the calculations anyway, to account for its "authenticator request" thing.
https://www.rfc-editor.org/rfc/rfc9261.html#section-5.2.2-8
https://www.rfc-editor.org/rfc/rfc9261.html#name-finished

Aside: this is a much, much better Handshake Context than post-handshake auth. Post-handshake auth forces you to retain the running hash, which contains a partial block. This one falls out of the exporter secret so we don't increase per-connection memory.

It's just a big change at this point in the process, so it's an opportunity to break things.

Totally fair. I wasn't sure whether we wanted this much surgery myself. :-)

[davidben]

Addressed @martinthomson's comments.

[muhammad-usama-sardar]

Aside: this is a much, much better Handshake Context than post-handshake auth.

I am not following the comparison you are trying to make here. Are you comparing the Handshake Context in RFC8446bis vs. Handshake Context in RFC9261? If so, I don't think the comparison is useful.

Post-handshake auth forces you to retain the running hash, which contains a partial block. This one falls out of the exporter secret so we don't increase per-connection memory.

I don't understand this. Could you please explain? In particular, what exactly do you mean by "partial block"?