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.
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
Add HRR compliance comments and tests for TLS RFC section 4.2.8 #3362
Add HRR compliance comments and tests for TLS RFC section 4.2.8 #3362
Changes from 1 commit
707cad8
2e43c0a
df36987
ea0a1f9
5725d38
0df8df9
36cf6a7
75009a9
bb0302b
18f74e7
88dc849
386e42e
9373fc8
c1e9166
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Even with early data, don't you need to offer a correct selected group? Why is there an exception for early data?
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.
Yes, a correct selected group still needs to be offered. This exception is for this line:
s2n-tls/tls/s2n_server_hello_retry.c
Lines 107 to 108 in 5725d38
Without the exception, I think there should not be a check for
conn->early_data_state == S2N_EARLY_DATA_REJECTED
. It seems like this condition is here to allow for HRRs to not modify the selected_group field if the HRR was sent only for the purpose of rejecting early data. I think this makes sense, because if you're only rejecting early data it wouldn't make sense to also need to update the selected_group. However, this condition does not seem to be present in the RFC.Here is the relevant part:
Checks (1) and (2) must both succeed. And, according to check (2),
new_key_share_requested
should always be true. So, the exception I added is for this statement:Since we allow check (2) to be false if early data was rejected.
Let me know if I'm misunderstanding something or if we actually should not be making this exception!
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.
I think the misunderstanding comes from the fact that the HelloRetryRequest doesn't have to include a keyshare extension. A server who is using a HRR to reject early data would not include a keyshare extension in that request. So the client doesn't need to make an exception in this case. Basically, if the server includes a keyshare extension in its HRR, it has to be asking for a keyshare change, otherwise the server can just leave that extension out.
So what I'm saying is, at minimum, there is no exception to the RFC. However, the existing code might need to be rewritten for the case where the server uses HRR to reject early data. 😪 @lrstewart do you know if we have a test for this?
This paragraph shows that the keyshare extension is optional in a HRR:
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group.
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.
Ah, got it okay. That makes sense. I was thinking that the extension was required for some reason.
So would the change be to check to see if a key share extension was received in
s2n_server_hello_retry_recv
, and if it was, ensure that check (2) succeeds here, and if it wasn't received, only check to see ifconn->early_data_state == S2N_EARLY_DATA_REJECTED
?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.
I think what I would do is gate line 71-107 with the check that the client actually received a keyshare extension. And then you can remove the early data rejected clause from the posix_ensure statement.
It seems like we have a test for this situation: https://github.com/aws/s2n-tls/blob/main/tests/unit/s2n_client_early_data_indication_test.c#L412.
But I think this test is flawed, because it's not appropriately mocking how a server would send a HRR if it wanted to reject early data. The server in this case should write the HRR without the keyshare ext.
Basically, additionally, I think we need to change the test so that the server excludes the keyshare ext.
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.
After looking at bouncy castle and openssl, it seems like implementations require a key share extension and don't provide an exception for early data. I therefor removed the exception, and fixed two failing tests that relied on not needing to update the selected_group: 36cf6a7
I also removed a test that checked for this specific exception that no longer exists: 75009a9