-
Notifications
You must be signed in to change notification settings - Fork 741
Rework representation of extensions in ClientHello
#2502
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 differencesClick to expand
Other differencesClick to expand
Additional informationCheckout details:
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2502 +/- ##
==========================================
- Coverage 95.40% 95.33% -0.07%
==========================================
Files 97 97
Lines 21881 21768 -113
==========================================
- Hits 20875 20752 -123
- Misses 1006 1016 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
fa3bee7
to
6130e46
Compare
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.
Good stuff!
On dev-0.24, should we use a newtype |
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.
Very nice! 🌠
Shortly extension bodies will be required to `impl Codec`, so this type will be used for extensions without a body.
Instead of `Vec<ClientExtension>`, store the extension data as a struct. This is possible because past commits have removed the need for this us to losslessly round-trip extension data. This involves fewer allocations to construct the extensions for clients. It eliminates repeated iteration of the vector to find specific extensions when processing a `ClientHello` for servers. It also reduces the cost of detecting duplicate extensions, which is moved into the decoding process -- a new `InvalidMessage::DuplicateExtension` error is introduced for this purpose. The struct is produced by a macro, which externalises the overall encoding and decoding operations. This allows specialisation for order of encoding (for ClientHello extension order randomisation) and whether an empty input is allowed (for ClientHello extensions in TLS1.2). During decoding a ClientHello, validate that any PSK offer appears last. This replaces `ClientHelloPayload::check_psk_ext_is_last`. Now that we have a specific error for this we can produce the error bogo expects for this case.
6130e46
to
f04d7b5
Compare
This is the prefix of #1475. See the commit message of the "Introduce
ClientExtensions
type" commit for explanation.This is part one in a three-part series. After this comes: #2508 and #2509.