diff --git a/docs/architecture/tls13-experimental.md b/docs/architecture/tls13-experimental.md index 88d0b73ddc..859ff2b8b6 100644 --- a/docs/architecture/tls13-experimental.md +++ b/docs/architecture/tls13-experimental.md @@ -133,17 +133,25 @@ MVP definition (1) This is just for comparison. - (2) The MVP sends one shared secret corresponding to the configured preferred - group. The preferred group is the group of the first curve in the list of - allowed curves as defined by the configuration. The allowed curves are - by default ordered as follow: `secp256r1`, `x25519`, `secp384r1` - and finally `secp521r1`. This default order is aligned with the - list of mandatory-to-implement groups (in absence of an application - profile standard specifying otherwise) defined in section 9.1 of the - specification. The list of allowed curves can be changed through the - `mbedtls_ssl_conf_curves()` API. + (2) The MVP sends only one shared secret corresponding to the configured + preferred group. This could, however end up with connection failure if the + server does not support our preferred curve, as we have yet to implement + 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 + mandatory-to-implement groups (in absence of an application profile + standard specifying otherwise) as defined in section 9.1 of the + specification gives the preferred order as follows: `secp256r1`, `x25519`, + `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 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