Buy commercial curl support from
WolfSSL. We help you work out your issues, debug your libcurl
applications, use the API, port to new platforms, add new features and more.
With a team lead by the curl founder himself.
Re: When will we make TLS 1.3 support a mandatory requirement?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeffrey Walton via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 7 Mar 2024 03:37:24 -0500
On Thu, Mar 7, 2024 at 3:15 AM Daniel Stenberg via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> The TLS 1.3 spec (RFC 8446) was published in August 2018. Over five years ago.
>
> According to radar.cloudflare.com about 93.8% of TSL-using Internet traffic is
> now using TLS 1.3 (or QUIC, which uses TLS 1.3 internally).
>
> At the same time, *three* of the libraries that curl supports do not do TLS
> 1.3 (together with curl): mbedTLS, BearSSL and Secure Transport. Libraries
> that seem to be a little "stuck in the past". I'm not sure if it is a valid
> concern, but if they don't even keep up with a five year old TLS version bump
> that is used widely, what else are they not keeping up with?
>
> I am aware that there are quite a few users using curl with those libraries.
> But maybe they should not?
>
> I would like to discuss the possibility that we set a flag day on which we cut
> off support for all TLS libraries that do not play TLS 1.3. I don't think it
> is urgent, so we can plan ahead, but I think it would be good for the greater
> community and for curl and Internet users everywhere. We could for example set
> it to end of June 2025 or something to allow everyone plenty of time to act,
> react, argue and wave their hands.
>
> Or is it too strict?
I feel like questions like "Allow TLS 1.0 and above or not", "Allow
TLS 1.2 or not" or "Require TLS 1.3" are policy decisions that the
application authors should make. Businesses and application authors
are in the best position to determine their needs. I don't think
library authors should make the decision.
Using TLS 1.2 is not too egregious. TLS v1.2 provides the
authenticated encryption modes of operation, like AES/GCM. The
protocol and cipher suites are likely acceptable to a business or
application author.
TLS v1.3 is certainly faster and more efficient in an optimal
configuration. x25519 key exchange and ed25519 signatures are about
10x to 20x faster based on my benchmarks compared to ECDHE and ECDSA.
(Key exchange is the bottleneck in TLS. Bulk encryption using AES or
ChaCha is super fast).
TLS v1.0 and TLS v1.1 are losing favor and falling off distro
configurations. My Ubuntu 20.04 web server using Apache with OpenSSL
does not even offer them. There's no need to make a policy decision
here.
SSLv2 and SSLv3 are already gone. I'm not aware of a distro that
enables them. There's no need to make a policy decision here.
And I am not sure how other protocols like QUIC intersect with TLS
1.3. It would be unfortunate if QUIC lost functionality due to loss of
TLS v1.2. But like I said, I don't know if this is even the case.
Jeff
Date: Thu, 7 Mar 2024 03:37:24 -0500
On Thu, Mar 7, 2024 at 3:15 AM Daniel Stenberg via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> The TLS 1.3 spec (RFC 8446) was published in August 2018. Over five years ago.
>
> According to radar.cloudflare.com about 93.8% of TSL-using Internet traffic is
> now using TLS 1.3 (or QUIC, which uses TLS 1.3 internally).
>
> At the same time, *three* of the libraries that curl supports do not do TLS
> 1.3 (together with curl): mbedTLS, BearSSL and Secure Transport. Libraries
> that seem to be a little "stuck in the past". I'm not sure if it is a valid
> concern, but if they don't even keep up with a five year old TLS version bump
> that is used widely, what else are they not keeping up with?
>
> I am aware that there are quite a few users using curl with those libraries.
> But maybe they should not?
>
> I would like to discuss the possibility that we set a flag day on which we cut
> off support for all TLS libraries that do not play TLS 1.3. I don't think it
> is urgent, so we can plan ahead, but I think it would be good for the greater
> community and for curl and Internet users everywhere. We could for example set
> it to end of June 2025 or something to allow everyone plenty of time to act,
> react, argue and wave their hands.
>
> Or is it too strict?
I feel like questions like "Allow TLS 1.0 and above or not", "Allow
TLS 1.2 or not" or "Require TLS 1.3" are policy decisions that the
application authors should make. Businesses and application authors
are in the best position to determine their needs. I don't think
library authors should make the decision.
Using TLS 1.2 is not too egregious. TLS v1.2 provides the
authenticated encryption modes of operation, like AES/GCM. The
protocol and cipher suites are likely acceptable to a business or
application author.
TLS v1.3 is certainly faster and more efficient in an optimal
configuration. x25519 key exchange and ed25519 signatures are about
10x to 20x faster based on my benchmarks compared to ECDHE and ECDSA.
(Key exchange is the bottleneck in TLS. Bulk encryption using AES or
ChaCha is super fast).
TLS v1.0 and TLS v1.1 are losing favor and falling off distro
configurations. My Ubuntu 20.04 web server using Apache with OpenSSL
does not even offer them. There's no need to make a policy decision
here.
SSLv2 and SSLv3 are already gone. I'm not aware of a distro that
enables them. There's no need to make a policy decision here.
And I am not sure how other protocols like QUIC intersect with TLS
1.3. It would be unfortunate if QUIC lost functionality due to loss of
TLS v1.2. But like I said, I don't know if this is even the case.
Jeff
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-03-07