-
Notifications
You must be signed in to change notification settings - Fork 743
Do not retain master secret during terminal key schedule state #2540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Benchmark resultsInstruction countsSignificant differencesClick to expand
Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2540 +/- ##
==========================================
+ Coverage 95.31% 95.32% +0.01%
==========================================
Files 97 97
Lines 21565 21614 +49
==========================================
+ Hits 20555 20604 +49
Misses 1010 1010 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes me wonder (again): should we have a separate types for an in-handshake connection, vs the long-term traffic connection, or would that affect the ergonomics too much? Maybe there should be an inner TrafficConnection
type that you can turn a ClientConnection
or ServerConnection
into that has minimal state?
`KeyScheduleBeforeFinished` encapsulates the first tranche of final derivations that do not include the client's finished message in the transcript. `KeyScheduleTraffic` contains all such final derivations, which means the client does not need to hang on to the transcript or rederive the resumption secret.
For servers, we can be sure we don't require this once we have sent all tickets. That means we can erase `KeyScheduleResumption` once that happens. For clients there's no ability to know a server has sent all possible tickets, so we have to keep this hanging around.
db404af
to
12a4188
Compare
This PR is a step toward #945, but for now arranges that the TLS1.3 "master secret" is erased in the terminal state. Doing that means that secrets derived from that are impossible to rederive later.
Unconditionally deriving the resumption secret has some performance consequences: