-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Make use of FFDH keys in TLS 1.3 v.2 #7627
Conversation
e6d6df0
to
211a676
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.
Looks pretty good overall, most points are fairly minor, except the reliance on dhm.h
which I think is structurally no what we want at this point.
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.
Thanks for addressing my feedback! I like what you've done with the functions that handle human-readable names, I think it's really neat now.
I also like the unification of ECDH and FFDH when writing our key share, but I have a number of suggestions to improve it further.
Edit: see also: #7627 (comment) and #7627 (comment)
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.
Looks good to me, but while the iron's hot, let's try to improve as discussed here (new helper macro + trying to de-duplicate code unless it turns out to be harder than I think).
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.
LGTM, thanks!
Force-pushed the following fix:
Edit: |
@mprse I think we also need to cast the argument: |
CI was green and I added only the last commit to fix comments (shouldn't cause any harm). |
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Force pushed last commit to restart CI as it seems it was aborted (not sure now if my happiness from green CI wasn't too early) . Also it seems that there is still problem with ffdh8192 on CI (even with one retry):
|
Do we really need to use the largest ffdh group in tests? Or could we only test with ffdhe2048 and ffdhe3072 in all the compat tests in order to avoid the performance issues? Perhaps keep only one test with ffdh8072 in order to make sure buffer sizes are correct, but that one would be guarded by Wdyt? |
First we had all groups tested but this was too much, so we decided to have only corner cases (smallest and biggest group). This makes sense, but since we have such problems on CI maybe using FFDHE6144 instead FFDHE8192 would be enough? |
I think we need to differentiate our strategy based on what we're testing. It looks to me like the numerous "TLS 1.3 X->Y: HRR zzz -> ttt" are mostly about negotiation by means of HelloRetryRequest: here I think we don't care about using large groups, and just using any two distinct groups would be enough, so I'd pick the two smallest groups. Then I think we need one test using the largest group with ourselves to validate buffer sizes. Then one interop test with each group with GnuTLS and/or OpenSSL to make sure we don't have group-specific errors (such as a typo in the group parameters or their IDs). (Note: this might apply to curves as well. I'm not sure we need to test absolutely all combinations of curves either in the HelloRetryRequest tests.) @ronald-cron-arm wdyt? |
Should these tests be manually added to So I will leave only
|
That was my thinking, yes. |
Yes that looks reasonable to me. |
That looks good to me. |
I am ok with that. |
- Full tests generated by script only for ffdhe2048 group - Single G->m and m->G exchange test for each other group Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
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.
LGTM. Good job!
I had a look at the API-ABI report, and the changes are acceptable: two internal functions have been renamed. |
Created follow-up PR that address remaining comments. |
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.
LGTM given that we've agreed to address remaining comments in a follow-up PR. I have also created a follow-up PR to try and improve one part of the code (#7862).
@@ -67,6 +67,7 @@ | |||
'secp521r1': 0x19, | |||
'x25519': 0x1d, | |||
'x448': 0x1e, | |||
'ffdhe2048': 0x100, |
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.
'ffdhe2048': 0x100, | |
# Only one finite field group to keep testing time within reasonable bounds. | |
'ffdhe2048': 0x100, |
I am happy for this to be done in the follow-up PR.
Description
Resolves: #5979
Continuation of: #6102
Needs: #7577
This PR adds support for FFDH keys and uses structures and adapts code used for ECDH computation.
Provides only mbedtls tests in
ssl-opt.sh
PR checklist
Please tick as appropriate and edit the reasons (e.g.: "backport: not needed because this is a new feature")