TLS used to prefer larger curves, under the idea that a larger curve has a
higher security strength and is therefore harder to attack. However, brute
force attacks are not a practical concern, so this was not particularly
meaningful. If a curve is considered secure enough to be allowed, then we
might as well use it.
So order curves by resource usage. The exact definition of what this means
is purposefully left open. It may include criteria such as performance and
memory usage. Risk of side channels could be a factor as well, although it
didn't affect the current choice.
The current list happens to exactly correspond to the numbers reported by
one run of the benchmark program for "full handshake/s" on my machine.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Upgrade the default list of hashes and curves allowed for TLS. The list is
now aligned with X.509 certificate verification: hashes and curves with at
least 255 bits (Curve25519 included), and RSA 2048 and above.
Remove MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_KEY_EXCHANGE which would no
longer do anything.
Document more precisely what is allowed by default.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
No change here, these were already mandatory, it just wasn't explicit in
the documentation.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Conflicts:
include/mbedtls/ssl.h
include/psa/crypto_struct.h
Conflicts fixed by using the code from development branch
and manually re-applying the MBEDTLS_PRIVATE wrapping.
ssl_server2 had a check that we never try to use a minor version lower
than 2 with DTLS, but that check is no longer needed, as there's no way
that would happen now that MBEDTLS_SSL_MINOR_VERSION_1 is no longer
public.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This commit removes the API
```
mbedtls_ssl_conf_ciphersuites_for_version()
```
which allows to configure lists of acceptable ciphersuites
for each supported version of SSL/TLS: SSL3, TLS 1.{0,1,2}.
With Mbed TLS 3.0, support for SSL3, TLS 1.0 and TLS 1.1
is dropped. Moreover, upcoming TLS 1.3 support has a different
notion of cipher suite and will require a different API.
This means that it's only for TLS 1.2 that we require
a ciphersuite configuration API, and
```
mbedtls_ssl_conf_ciphersuites()
```
can be used for that. The version-specific ciphersuite
configuration API `mbedtls_ssl_conf_ciphersuites_for_version()`,
in turn, is no longer needed.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The previous documentation could be read as exhaustively listing
the factors that go into computing the maximum outgoing record
plaintext size -- we should give examples, but allow ourselves
to add more factors in the future.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
This commit makes the API
- mbedtls_ssl_get_output_max_frag_len()
- mbedtls_ssl_get_input_max_frag_len()
- mbedtls_ssl_get__max_frag_len()
for querying the state of the Maximum Fragment Length
extension internal.
Rationale: The value those APIs provide to the user is in
upper bounds for the size of incoming and outgoing records,
which can be used to size application data buffers apporpriately
before passing them to mbedtls_ssl_{read,write}(). However,
there are other factors which influence such upper bounds,
such as the MTU or other extensions (specifically, the
record_size_limit extension which is still to be implemented)
which should be taken into account.
There should be more general APIs for querying the maximum
size of incoming and outgoing records.
For the maximum size of outgoing records, we already have such,
namely mbedtls_ssl_get_max_out_record_payload().
For the maximum size of incoming records, a new API will be
added in a subsequent commit.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Conflicts:
library/version_features.c
programs/test/query_config.c
Files were removed in development branch and modified by current branch.
Conflicts fixes by removing them.
Conflicts:
* configs/config-psa-crypto.h: modified here, removed in development
* tests/suites/test_suite_x509parse.data: all conflicts are in depends_on
lines where development made a change unrelated to MBEDTLS_SHAxxx and our
branch either changed `MBEDTLS_SHA256_C` to `MBEDTLS_SHA224_C` or
`MBEDTLS_SHA512_C:!MBEDTLS_SHA512_NO_SHA384` to ``MBEDTLS_SHA384_C`, with
no change to what the test does. Pick the other branch's dependency
changes then apply our SHA dpeendency change.
