From 66491c7d087859a7ffc4fd9711b804078cd261bf Mon Sep 17 00:00:00 2001 From: Paul Elliott Date: Fri, 26 Nov 2021 20:24:43 +0000 Subject: [PATCH 1/5] Edit docs to explain not changing curve order 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 --- docs/architecture/tls13-experimental.md | 28 ++++++++++++++++--------- 1 file changed, 18 insertions(+), 10 deletions(-) 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 From 89c8e098ee6ba0784af76ee912c39ccb5912e1cf Mon Sep 17 00:00:00 2001 From: Paul Elliott Date: Tue, 30 Nov 2021 10:54:52 +0000 Subject: [PATCH 2/5] Convert tabs to spaces Signed-off-by: Paul Elliott --- docs/architecture/tls13-experimental.md | 32 ++++++++++++------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/architecture/tls13-experimental.md b/docs/architecture/tls13-experimental.md index 859ff2b8b6..389b81eabf 100644 --- a/docs/architecture/tls13-experimental.md +++ b/docs/architecture/tls13-experimental.md @@ -134,22 +134,22 @@ MVP definition (1) This is just for comparison. (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. + 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 negotiation. Out-of-protocol fallback is supported though if the Mbed TLS library From fe0894424617b6b6e8eddd8bc276aef6639dd8ff Mon Sep 17 00:00:00 2001 From: Paul Elliott Date: Tue, 30 Nov 2021 10:55:53 +0000 Subject: [PATCH 3/5] Fix spelling error Signed-off-by: Paul Elliott --- docs/architecture/tls13-experimental.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/tls13-experimental.md b/docs/architecture/tls13-experimental.md index 389b81eabf..15a38f0d5d 100644 --- a/docs/architecture/tls13-experimental.md +++ b/docs/architecture/tls13-experimental.md @@ -145,7 +145,7 @@ MVP definition `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 + difficult (we have no desire to change TLS1.2 behaviour). The likelihood 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 From c0d335bc1e7203fe8f77da306b41b39d3cf026e5 Mon Sep 17 00:00:00 2001 From: Paul Elliott Date: Thu, 2 Dec 2021 16:38:05 +0000 Subject: [PATCH 4/5] Second draft of explanation Signed-off-by: Paul Elliott --- docs/architecture/tls13-experimental.md | 28 ++++++++++++------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/docs/architecture/tls13-experimental.md b/docs/architecture/tls13-experimental.md index 15a38f0d5d..0c363a3520 100644 --- a/docs/architecture/tls13-experimental.md +++ b/docs/architecture/tls13-experimental.md @@ -134,22 +134,20 @@ MVP definition (1) This is just for comparison. (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 + preferred group. This could end up with connection failure if the + 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 - 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 likelihood - 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. + the list of allowed curves as defined by the configuration. The allowed + curves are by default ordered as follows: `x25519`, `secp256r1`, + `secp384r1` and finally `secp521r1`. Note that, in the absence of an + application profile standard specifying otherwise, section 9.1 of the + specification rather promotes curve `secp256r1` to be supported over + curve `x25519`. The MVP would, hoewever, rather keep the preference order + currently promoted by Mbed TLS as this applies to TLS 1.2 as well, and + changing the order only for TLS1.3 would be potentially difficult. + In the unlikely event a server does not support curve `x25519` but does + support curve `secp256r1`, curve `secp256r1` can be set as the preferred + curve through the `mbedtls_ssl_conf_curves()` API. (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 From cce0f5a085c8f0fc62afe0fa19b23dd021906ffa Mon Sep 17 00:00:00 2001 From: Paul Elliott Date: Fri, 3 Dec 2021 16:13:30 +0000 Subject: [PATCH 5/5] Fix typo Signed-off-by: Paul Elliott --- docs/architecture/tls13-experimental.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/tls13-experimental.md b/docs/architecture/tls13-experimental.md index 0c363a3520..4cefba2215 100644 --- a/docs/architecture/tls13-experimental.md +++ b/docs/architecture/tls13-experimental.md @@ -142,7 +142,7 @@ MVP definition `secp384r1` and finally `secp521r1`. Note that, in the absence of an application profile standard specifying otherwise, section 9.1 of the specification rather promotes curve `secp256r1` to be supported over - curve `x25519`. The MVP would, hoewever, rather keep the preference order + curve `x25519`. The MVP would, however, rather keep the preference order currently promoted by Mbed TLS as this applies to TLS 1.2 as well, and changing the order only for TLS1.3 would be potentially difficult. In the unlikely event a server does not support curve `x25519` but does