Enable one more bogo ECH test, update skip reason for another #2061
Conversation
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
The upstream test has been updated so that the "unsupported KEM" is truly an unsupported option (0x666 not DHKEM(P-256, HKDF-SHA256)). However, we still can't enable this test. Our design parses the ECH configs up front and errors out of client configuration building if no ECH configurations are supported. The Bogo test expects that we ignore the request to use ECH and instead negotiate a connection that doesn't offer ECH. This commit updates the rationale for skipping the test to reflect this divergence in design.
Previously we had to ignore the `TLS-ECH-Client-SelectECHConfig` bogo test because we selected the "wrong" config. Before a bogo update the test included a number of unsupported configs alongside a config that should be supported, and asserted the correct config was selected. However, we happened to support the "unsupported KEM" and so would select the "wrong" config. Since the upstream bogo test has been updated to use a truly unsupported/unknown KEM we can now re-enable this test. Our implementation now selects the correct config.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2061 +/- ##
==========================================
+ Coverage 94.38% 94.41% +0.02%
==========================================
Files 98 98
Lines 23263 23263
==========================================
+ Hits 21957 21963 +6
+ Misses 1306 1300 -6 ☔ View full report in Codecov by Sentry. |
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:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Following #2057 I remembered there were two ECH related tests we marked skipped in b4eba48, pending upstream fixes.
Specifically there were two tests we couldn't handle (
TLS-ECH-Client-SelectECHConfigandTLS-ECH-Client-NoSupportedConfigs) because the test cases were using an "unsupported KEM" that we happened to support. This was fixed upstream w/ rustls/boringssl@d8d1c6a to use an unknown KEM ID that no implementations should happen to support.We can now enable
TLS-ECH-Client-SelectECHConfigwithout any required code changes on our side. UnfortunatelyTLS-ECH-Client-NoSupportedConfigsstill isn't workable because the test assumes if no ECH configs are supported the client will do a TLS handshake w/o offering ECH, where-as we prefer to fail the client configuration construction, returning an error about unsupported configs.As a result this branch enables
TLS-ECH-Client-SelectECHConfigand updates the reason for why we ignoreTLS-ECH-Client-NoSupportedConfigs.