-
Notifications
You must be signed in to change notification settings - Fork 597
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
Correct kx group selection #1784
Conversation
349420d
to
8f6cbed
Compare
Benchmark resultsInstruction countsSignificant differencesThere are no significant instruction count differences Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1784 +/- ##
==========================================
+ Coverage 95.92% 96.02% +0.09%
==========================================
Files 81 81
Lines 18803 18678 -125
==========================================
- Hits 18037 17935 -102
+ Misses 766 743 -23 ☔ View full report in Codecov by Sentry. |
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.
This looks good to me.
After skimming draft-davidben-tls-key-share-prediction-00 I expected there might be client changes needed here or in #1785 to track the notion of a prediction-safe supported group, but it looks like neither branch considers that. Am I overlooking something?
Sorry, yes, that isn't very clear. The only part I am fixing at this point is this paragraph:
I'm cherry-picking just that part, because our old way of selecting a group wasn't supported by RFC8446 (an RFC we definitely want to support as correctly as possible!), specifically this text:
(emphasis mine) I think if draft-davidben-tls-key-share-prediction-00 is adopted by the WG and becomes a real thing, then we should reflect the "prediction safe" concept (eg, |
Makes sense to me 👍 |
8ef4b8d
to
9725fab
Compare
In 3355e06 we generalised the error type here, but we didn't get rid of code that discarded the information-less error.
By ignoring everything not precisely expected, these ran the risk of incorrectly passing. eg, `assert_server_requests_retry_and_echoes_session_id` would pass if the server sent a `ServerHello`.
Prior to this, we preferred to avoid a `HelloRetryRequest` when any supported `KeyShare` was supplied. But as [1] describes, this means a client which sends a `KeyShare` for a less-preferred group would end up using that, rather than a more-preferred group supported by both peers. [1]: https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html#name-downgrades
This is complex because the choice of usable cipher suites depends on selected protocol version, and the set of mutually supported key exchange groups. Then, the usable set of key exchange groups depends on the actually-selected cipher suite.
Test the behaviour of `ServerConfig::ignore_client_order` at the public API level.
f8227dd
to
59532da
Compare
See https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ for background.
The first three commits are "the friends we made along the way".
fixes #1512