Skip to content
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

driver-only ECDSA: get testing parity in SSL #6860

Closed
mpg opened this issue Dec 30, 2022 · 0 comments · Fixed by #7064
Closed

driver-only ECDSA: get testing parity in SSL #6860

mpg opened this issue Dec 30, 2022 · 0 comments · Fixed by #7064
Assignees
Labels
enhancement size-m Estimated task size: medium (~1w)

Comments

@mpg
Copy link
Contributor

mpg commented Dec 30, 2022

Context: #6839.

This task is to progress TL-ecdsa.TLS by achieving testing parity in the SSL test suites (including debug which is part of SSL despite its name not reflecting it). Once it's done, in analyze_outcomes.py, the task analyze_driver_vs_reference_ecdsa will no longer ignore ssl nor debug.

This will likely consist of replacing uses of MBEDTLS_ECDSA_C with either:

  • checks based on MBEDTLS_KEY_EXCHANGE_xxx macros for most TLS 1.2 code (we may want to introduce a new macro to express "there's a key exchange that requires ECDSA" / "allows use of ECDSA" (client auth, see below), similarly to the existing MBEDTLS_SSL_HANDSHAKE_WITH_CERT_ENABLED);
  • the relevant macros defined in driver-only ECDSA: get testing parity in PK #6857 perhaps in some places in TLS 1.2 (client auth, see below), and in TLS 1.3 code that goes through PK;
  • PSA_WANT_ALG_ECDSA for TLS 1.3 code that calls PSA functions directly (if any).

Note that most of the time, MBEDTLS_KEY_EXCHANGE_xxx is the right choice: it doesn't matter that the library can do ECDSA if no key exchange using ECDSA is enabled. (It's also a matter of layering: we should not use feature macros from low-level modules if there are some closer to our level that can do the job.) However there are places where the choice of a signature algorithm is not determined by the key exchange. The one (and only one) I can think of is client authentication: even if the key exchange is RSA, it's legal for a client to authenticate itself using an ECDSA. So, when negotiating signature algorithms for client authentication, going to PK macros is probably the right thing to do.

For debug, we may choose to change the output format when USE_PSA is enabled.

Note: since this modifies dependency declarations, we'll want to use docs/architecture/psa-migration/outcome-analysis.sh on the PR that implements this.

Note: enabling more key exchanges in config_psa_crypto_config_ecdsa_use_psa is out of scope here, it will be a separate task.

Depends on: #6858

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement size-m Estimated task size: medium (~1w)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants