mirror/mbedtls
1
0
Fork 0
mirror of https://github.com/Mbed-TLS/mbedtls.git synced 2025-03-31 10:20:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Second draft of explanation

Browse Source 
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
This commit is contained in:
Paul Elliott 2021-12-02 16:38:05 +00:00
parent fe08944246
commit c0d335bc1e
1 changed files with 13 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -134,22 +134,20 @@ MVP definition
(1) This is just for comparison. (1) This is just for comparison.
(2) The MVP sends only one shared secret corresponding to the configured (2) The MVP sends only one shared secret corresponding to the configured
preferred group. This could, however end up with connection failure if the preferred group. This could end up with connection failure if the
server does not support our preferred curve, as we have yet to implement server does not support our preferred curve, as the MVP does not implement
HelloRetryRequest. The preferred group is the group of the first curve in HelloRetryRequest. The preferred group is the group of the first curve in
the list of allowed curves as defined by the configuration. The list of the list of allowed curves as defined by the configuration. The allowed
mandatory-to-implement groups (in absence of an application profile curves are by default ordered as follows: `x25519`, `secp256r1`,
standard specifying otherwise) as defined in section 9.1 of the `secp384r1` and finally `secp521r1`. Note that, in the absence of an
specification gives the preferred order as follows: `secp256r1`, `x25519`, application profile standard specifying otherwise, section 9.1 of the
`secp384r1` and finally `secp521r1`. If we could therefore fix the use of specification rather promotes curve `secp256r1` to be supported over
`secp256r1`, then we would be guaranteed that the server supported it, curve `x25519`. The MVP would, hoewever, rather keep the preference order
however our current curve preference order puts `x25519` before currently promoted by Mbed TLS as this applies to TLS 1.2 as well, and
`secp256r1` and changing this for only TLS1.3 would be potentially changing the order only for TLS1.3 would be potentially difficult.
difficult (we have no desire to change TLS1.2 behaviour). The likelihood In the unlikely event a server does not support curve `x25519` but does
of finding a server that doesn't support `x25519` is quite low and indeed support curve `secp256r1`, curve `secp256r1` can be set as the preferred
the end user could themselves change the order of preference of curves curve through the `mbedtls_ssl_conf_curves()` API.
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 negotiation. (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