mirror/mbedtls
1
0
Fork 0
mirror of https://github.com/Mbed-TLS/mbedtls.git synced 2025-04-16 08:42:50 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Edit docs to explain not changing curve order

Browse Source 
TLS1.3 MVP would benefit from a different curve group preference order
in order to not cause a HelloRetryRequest (which are not yet handled),
however changing the curve group preference order would affect both
TLS1.2 and TLS1.3, which is undesirable for something rare that can
be worked around.

Signed-off-by: Paul Elliott <paul.elliott@arm.com>
This commit is contained in:
Paul Elliott 2021-11-26 20:24:43 +00:00
parent e0bbedfe7a
commit 66491c7d08
1 changed files with 18 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/architecture/tls13-experimental.md
View File

@ -133,17 +133,25 @@ MVP definition
(1) This is just for comparison. (1) This is just for comparison.
(2) The MVP sends one shared secret corresponding to the configured preferred (2) The MVP sends only one shared secret corresponding to the configured
group. The preferred group is the group of the first curve in the list of preferred group. This could, however end up with connection failure if the
allowed curves as defined by the configuration. The allowed curves are server does not support our preferred curve, as we have yet to implement
by default ordered as follow: `secp256r1`, `x25519`, `secp384r1` HelloRetryRequest. The preferred group is the group of the first curve in
and finally `secp521r1`. This default order is aligned with the the list of allowed curves as defined by the configuration. The list of
list of mandatory-to-implement groups (in absence of an application mandatory-to-implement groups (in absence of an application profile
profile standard specifying otherwise) defined in section 9.1 of the standard specifying otherwise) as defined in section 9.1 of the
specification. The list of allowed curves can be changed through the specification gives the preferred order as follows: `secp256r1`, `x25519`,
`mbedtls_ssl_conf_curves()` API. `secp384r1` and finally `secp521r1`. If we could therefore fix the use of
`secp256r1`, then we would be guaranteed that the server supported it,
however our current curve preference order puts `x25519` before
`secp256r1` and changing this for only TLS1.3 would be potentially
difficult (we have no desire to change TLS1.2 behaviour). The likelyhood
of finding a server that doesn't support `x25519` is quite low and indeed
the end user could themselves change the order of preference of curves
using the `mbedtls_ssl_conf_curves()` API if they wished to do so, so we
are leaving the current preference order intact.
(3) The MVP proposes only TLS 1.3 and does not support version negociation. (3) The MVP proposes only TLS 1.3 and does not support version negotiation.
Out-of-protocol fallback is supported though if the Mbed TLS library Out-of-protocol fallback is supported though if the Mbed TLS library
has been built to support both TLS 1.3 and TLS 1.2: just set the has been built to support both TLS 1.3 and TLS 1.2: just set the
maximum of the minor version of the SSL configuration to maximum of the minor version of the SSL configuration to