-
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
Implement modified key export API for Mbed TLS 3.0 #4552
Implement modified key export API for Mbed TLS 3.0 #4552
Conversation
CI only failing because of the API break. |
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.
A couple of minor points, otherwise looks good
* \param client_random The client random bytes. | ||
* \param server_random The server random bytes. | ||
* \param tls_prf_type The identifier for the PRF used in the handshake | ||
* to which the key belongs. |
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.
Missing docs for secret and secret_len
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.
Fixing
include/mbedtls/ssl.h
Outdated
typedef enum | ||
{ | ||
MBEDTLS_SSL_TLS_PRF_NONE, | ||
MBEDTLS_SSL_TLS_PRF_TLS1, |
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.
Is MBEDTLS_SSL_TLS_PRF_TLS1 still needed after TLS 1.0 and 1.1 have been removed?
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.
No, it's not. I've removed it.
@daverodgman Thank you for your review. I believe to have addressed your comments. Could you please re-review? |
@ronald-cron-arm Why was this removed from the Mbed TLS 3.0 Optional EPIC? |
Because it is linked to the issue #4363 that is in the Mbed TLS 3.0 Optional EPIC and thus in the EPIC we can still see this PR through the issue. When a PR is linked to an issue that is an EPIC we prefer not to add the PR to the EPIC as well. EPICs are better organized that way. |
@ronald-cron-arm Got it! |
d63ab59
to
6b7bb36
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 good, comments have been addressed - thanks!
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've read the discussion in #2188 and #4363 and reviewed the proposal here.
I think the callback should have access to the SSL context. This was proposed in #2188 and I think this is both simpler and more future-proof than the proposed alternatives such as identifying a connection by its random. I don't see any rationale for the current choice of parameters for the callback.
* \brief Callback type: Export key alongside random values for | ||
* session identification, and PRF for | ||
* implementation of TLS key exporters. | ||
* |
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.
(Doesn't necessarily need to be answered now, but it may matter to the design of the API.) With MBEDTLS_USE_PSA_CRYPTO
, at some point, it will become possible to have session secrets that cannot be exported. Are we planning to just not call the callback?
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.
If the answer might be "don't call it", should we document now that under some circumstances (that we don't need to define at this point), the callback may not be called?
include/mbedtls/ssl.h
Outdated
* to which the key belongs. | ||
* | ||
* \return \c 0 if successful. | ||
* \return A negative error code on failure. |
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.
What happens if the callback fails? Right now the failure is ignored. Maybe the callback should return void? If not I think the effect of a failure should be a documented aspect of the API.
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.
Hmm, good point. At first I thought we should change the return type to void
, but perhaps it's a convenient for the user to be able to signal a fatal error to the stack when something goes wrong in the export. I'll implement and document the latter for now.
Let's wait for @mpg's opinion before changing anything.
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 returning void
is the right thing to do for this kind of callback. If anything goes wrong with the export for some reason, it doesn't invalidate anything in the connection - it might be a problem for the application, and then the application will decide what to do (including closing the connection if desired).
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 I agree with @mpg - not sure what Mbed TLS could usefully do with the error.
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.
Changing to void.
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.
For the record, I agree with @mpg's analysis.
Signed-off-by: Hanno Becker <[email protected]>
Signed-off-by: Hanno Becker <[email protected]>
Signed-off-by: Hanno Becker <[email protected]>
Fixes Mbed-TLS#2188 Signed-off-by: Hanno Becker <[email protected]>
Signed-off-by: Hanno Becker <[email protected]>
Signed-off-by: Hanno Becker <[email protected]>
This saves some code when compiling for Thumb, where access to fields with offset index > 127 requires intermediate address computations. Frequently used fields should therefore be located at the top of the structure, while less frequently used ones -- such as the export callback -- can be moved to the back. Signed-off-by: Hanno Becker <[email protected]>
b62ad8f
to
46b0217
Compare
Trivial rebase onto latest development to try re-running the CI |
Signed-off-by: Hanno Becker <[email protected]>
46b0217
to
296fefe
Compare
Yet another try... |
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
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 except for one omission in the migration guide.
Those APIs have been removed and replaced by the new API | ||
`mbedtls_ssl_set_export_keys_cb()`. This API differs from | ||
the previous key export API in the following ways: | ||
|
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.
Another way is that the new callback returns void, whereas the old callbacks returned an int value that was ignored. Since the old value was ignored, that's minor enough not to be mentioned in the changelog which is a high-level semantic overview, but I think it should be listed in the migration guide, because I'd expect the list here to be a complete list of steps to migrate existing code.
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.
Fair point, I've discussed wording with @hanno-arm & pushed a commit with the addition to the migration guide.
Signed-off-by: Dave Rodgman <[email protected]>
6d937ed
to
5ec5003
Compare
Sorry, typo in my first attempt. |
This resolves #4363 and implements the API proposed therein. See #4363 and the documentation for more information.