Open Izorkin opened 5 days ago
Yes. We will soon work with @sftcd and try to get his ECH work ported/PR'd here.
Thaks! Let me know if there's anything I can do to help you :)
You could copy over the PR and see if it works :). Not totally serious about taht.
I've agreed API changes with the openssl devs and some of that is already merged to an openssl feature branch here. Once about 2 more PRs are merged to that, then it should be fully functional (i.e. client and server working for ECH) so will likely be a better place from which to start. I hope that might be done before the end of the year. Happy to chat meantime if you want to start sooner, based on one of my own branches.
@sftcd I failed to apply the patch for quictls 3.3.0.
not a surprise;-) I've never looked at quictls so don't have good pointers for you now, might get a chance to look at it in a few weeks though, but not yet sorry
What PRs still need to be ported?
So quictls is based on oepnssl 3.3 which has NONE of the ECH work from @sftcd . Perhaps he can reach out to you off-line and suggest an approach? It's all in a 'feature branch' at openssl, so can probably fetch taht branch and do 'git log' to see what is needed?
Something seems to be working:
./result-bin/bin/openssl ech -help
Usage: ech [options]
General options options:
-help Display this summary
-verbose Provide additional output
-text Provide human-readable output
Key generation options:
-out outfile Private key and/or ECHConfig [default: echconfig.pem]
-public_name val public_name value
-max_name_len int Maximum host name length value [default: 0]
-suite val HPKE ciphersuite: e.g. "0x20,1,3"
-ech_version int ECHConfig version [default: 0xff0d (13)]
ECH PEM file downselect/display options:
-in infile An ECH PEM file
-select int Downselect to the numbered ECH config
well, the ECH code does work... promise:-)
question: is this something that needs doing now or would it be ok at the end of the year? If the latter that's easier, just due to time pressure. If there's a real reason to need to get done sooner, happy to chat about that. (In which case maybe a call to mutually-explain where there may square-pegs/round-holes etc. would be good.)
My opinion is end of year is fine. But if the original poster wants it sooner...
I don't know which variant would be better. But I've wanted to test ech at my server for a long time, but I didn't want to give up quic protocol support.
OpenSSL is doing a QUIC implementation, it is not complete, and the person who did most of the code left the project. QuicTLS has had QUIC support for years, ever since OpenSSL rejected the PR -- the difference is you have to use one of the existing open source implementations (MSQUIC, Google's, etc). They are complete and production quality. Use whatever you think best, it's a judgement call.
In my opinion, QuicTLS will get ECH before OpenSSL will get a complete QUIC.
Just to be clear: I'll happily stay out of the politics of quictls vs. an openssl quic implementation if that's ok:-)
On timing: I'm happy to help with integrating ECH here, but think it'll be better to start on that based on the openssl feature branch mentioned above, once that feature branch is in a working state (end of 2024 hopefully). That should mean that it'll be much easier for this project to keep ECH stuff working without too much effort whenever you pull in a new version of openssl. If we started now, based on the working ECH code from an @sftcd branch, there'd more likely be a bunch of wasted effort involved every time this project wants a new openssl version, so I figure it's better to avoid that. Secondarily, it'll take me a bit of time to get my head around any changes to ECH code needed for quic, and I'll have more time for that in the new year than now.
I agree with @sftcd's suggestions: I did not realize that the feature branch isn't quite ready yet.
Yeah, about 2 more PRs need merging to it before it'll be fully functional for ECH. You can see what that might look like in my both-sides-now branch but better to wait 'till that's gotten openssl maintainer review and been merged to the feature branch before basing any work on it.
Is it now possible to add support for ECH?