state of play of ECH feature branch (2)

[Stephen Farrell]

Hi all,

Now that we've gotten the first 3 PRs merged to the
ECH feature branch, it's time for the next one, that
includes ECH client-side code. (That's PR#26011 just
created a few minutes ago.)

My updated state-of-play and rough plan for future PRs
is below.

For various reasons, it'd be really great if we could
get this and the ECH server side code merged to the
feature branch by the end of the year. Once we have
that, then the feature branch can be used as the
basis for PRs to other projects (e.g. lighttpd, nginx
etc.) so those can seriously start thinking about how
to include an ECH-enabled OpenSSL in their plans.

Cheers,
S.

# Rough plan for future ECH PRs to feature branch

2024-11-20, sftcd

0. PR#24738, Initial APIs document
started: 2024-06-26, merged: 2025-08-15
1. PR#25420: ECH CLI implementaiton
started: 2024-09-10, merged: 2024-10-10
2. PR#25663 ECH external APIs
started: 2024-10-10, merged: 2024-11-20
- mostly memory management, external API and
`ssl/ssl_lib.c` init/free stuff
- shouldn't be too hard, expected issues:
- up-ref'ing or not
- what to store in `SSL_CTX` and the SSL connection
for ECH (that'll either involve looking ahead to
transcript handling or punting some discussion 'till
the subsequent PR)
3. *WE ARE HERE* PR#26011: ECH client side
started: 2024-11-20, merged: TBD
- client-side extension handling and client hello production
- lots of possible discussion points, incl:
- how I've "wrapped" `tls_construct_client_hello()`
- compile-time ability to choose how to handle which
exts with ECH (incl. default choices)
- transcript handling and outer CH tweaks (see #6
below though, likely better to do some of that
after #5)
4. ECH "both sides now" - server-side ECH decryption
- wasn't hard since mostly deteremined by the ECH
client side stuff
5. ECH more `s_client` and `s_server`
- probably many small issues with CLI arguments
6. ECH tweaks
- a refactor of transcript hashing might well be needed,
depending on comments on #3 above - likely better to
wait to do this after #5 as it'll be a lot easier to
test changes and be sure they work for a wider range
of test cases
- consider whether to make our outer CH look like one
from a browser (via extension re-ordering) and similarly
make it (harder?) to differentiate GREASEy ECH vs.
real (again perhaps via extension re-ordering) and
whether to GREASE by default or not
7. fuzzing and external tests
8. getting OTF "red-team" review and processing results of
that (OTF fund pentesters to review code, so we plan to ask
for such a review for the feature branch)
9. likely next will be more tests and odds'n'ends (anything
not done 'till then for e.g. HRR, early-data, or sessions)
10. ECH split-mode
11. anything that turns up while re-doing the ECH integrations
with curl, nginx, etc. with the new APIs (maybe >1 PR)
12. end-game PR (no idea what'll be in that, but at least
tests/docs/coverage I guess:-)