Move The Transcript Hash to earlier in the document#1404
Open
davidben wants to merge 4 commits intotlswg:mainfrom
Open
Move The Transcript Hash to earlier in the document#1404davidben wants to merge 4 commits intotlswg:mainfrom
davidben wants to merge 4 commits intotlswg:mainfrom
Conversation
As previously written, it suggests the message sequence does not change at all, but it is actually (as the text suggests), the transcript of everything sent or received. This still doesn't quite make us robust to extensions. The CertificateVerify and Finished messages are defined in terms of this "Handshake Context" that is written using phrases like * "later of EncryptedExtensions/CertificateRequest" * "later of server Finished/EndOfEarlyData" * "ClientHello ... client Finished + CertificateRequest" And then sometimes Certificate and CertificateVerify are explicitly appended to it. Interestingly, that is also a bit goofy because we don't always account for those messages not existing in the prose. This PR leaves all that alone for now, because I haven't quite written something down for that yet. (I think the right wording is to say "hash all the messages up to but not including Finished/CertificateVerify.)
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.
It is a little strange that it is buried inside Authentication Messages, but then it's referenced all throughout the document. This seems enough of a core component of the handshake protocol to describe it first. NB: This will cause almost all the section numbers between RFC 8446 and rfc8446bis to be different. Folks will need to take some care when updating references.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Only look at the last commit in this stack. This PR includes #1401, #1402, and #1403. GitHub is bad at stacked PRs. I'll rebase this one once decisions on the other three PRs is made.
It is a little strange that it is buried inside Authentication Messages, but then it's referenced all throughout the document. This seems enough of a core component of the handshake protocol to describe it first.
NB: This will cause almost all the section numbers between RFC 8446 and rfc8446bis to be different. Folks will need to take some care when updating references.