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: Feature window: open
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stephen Farrell <stephen.farrell_at_cs.tcd.ie>
Date: Mon, 23 Oct 2023 11:24:49 +0100
Hiya,
On 23/10/2023 07:46, Daniel Stenberg wrote:
> On Sat, 21 Oct 2023, Stephen Farrell via curl-library wrote:
>
>> I'm not clear how you like to handle experimental things like our ECH PR.
>
> This work still uses a custom patch on OpenSSL, right?
Yep. Latest branch is [1]. That code's been pretty stable
for a while now, but of course hasn't had serious review
from OpenSSL maintainers, so processing a PR before a
merge is likely to take a while.
> Do you have any
> idea if/when that might actually land in OpenSSL proper?
Not sure. OpenSSL have a policy of not merging such PRs until
the relevant RFC has issued, so earliest would be then. And of
course when the IETF finishes its work and gets the RFC out
the door is also a moveable feast.
My guess is around March-April next year. I plan to create
a PR for OpenSSL around the end of the year in the hope they
start to review beforehand to reduce the delay. But that's
a guess and things could take longer.
> I assume the BoringSSL and wolfSSL sides of things are already merged
> upstream?
I believe so. However, it's still worth giving them some
time too as they (and my OpenSSL fork) currently use an
experimental TLS codepoint for the ECH extension. A final
codepoint should be allocated soon and will I assume then
be used by those libraries, but it'd likely be best if e.g.
nobody shipped a statically linked binary using those TLS
stacks until after they've incorporated the new codepoint.
My guess is that codepoint will be allocated and could be
in those libraries before the end of this year.
Cheers,
S.
[1] https://github.com/sftcd/openssl/tree/ECH-draft-13c
Received on 2023-10-23
Date: Mon, 23 Oct 2023 11:24:49 +0100
Hiya,
On 23/10/2023 07:46, Daniel Stenberg wrote:
> On Sat, 21 Oct 2023, Stephen Farrell via curl-library wrote:
>
>> I'm not clear how you like to handle experimental things like our ECH PR.
>
> This work still uses a custom patch on OpenSSL, right?
Yep. Latest branch is [1]. That code's been pretty stable
for a while now, but of course hasn't had serious review
from OpenSSL maintainers, so processing a PR before a
merge is likely to take a while.
> Do you have any
> idea if/when that might actually land in OpenSSL proper?
Not sure. OpenSSL have a policy of not merging such PRs until
the relevant RFC has issued, so earliest would be then. And of
course when the IETF finishes its work and gets the RFC out
the door is also a moveable feast.
My guess is around March-April next year. I plan to create
a PR for OpenSSL around the end of the year in the hope they
start to review beforehand to reduce the delay. But that's
a guess and things could take longer.
> I assume the BoringSSL and wolfSSL sides of things are already merged
> upstream?
I believe so. However, it's still worth giving them some
time too as they (and my OpenSSL fork) currently use an
experimental TLS codepoint for the ECH extension. A final
codepoint should be allocated soon and will I assume then
be used by those libraries, but it'd likely be best if e.g.
nobody shipped a statically linked binary using those TLS
stacks until after they've incorporated the new codepoint.
My guess is that codepoint will be allocated and could be
in those libraries before the end of this year.
Cheers,
S.
[1] https://github.com/sftcd/openssl/tree/ECH-draft-13c
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature