working towards a PR for ECH

[Stephen Farrell]

Hi all,

Me again:-)

I've learned a lot from the extended processing of my
HPKE PR [1] and was pondering how to proceed to get a
PR for ECH ready for processing. (Thanks again to all
of you who helped get [1] over the line, and apologies
for being so inept along the way:-)

TL:DR; suggestion is: create a mailing list for those
interested in commenting on or watching the code that
might end up being that PR; I'm happy to create such a
list @tcd.ie or for it to be @openssl.org (presumably
with an anyone-can-subscribe/open-archive setup).

Reasons:

- This is going to take a while, might interact with
the quic stuff you're doing, and some of the likely
politics (e.g. browsers turning ECH on by default)
will likely benefit from a focused venue for technical
implementation discussion

- It's defo premature to produce a PR now, as the ECH
draft [2] isn't yet an RFC, so you can't merge as per
policy (a good policy), and my learnings from [1] are
that my code [3] as-is definitely needs a large pile
of work [/me being a willing worker still:-)]

- The draft [2] is quite mature though, being deployed
at a test cloudflare instance and (behind a flag) in
released browsers, with interop already, (including
with my test servers [4]) so it'd be a shame to fall
behind by a year or more after the RFC pops out, were
that due to not having a way to get ready beforehand

- It'd seem sensible to discuss ECH APIs ahead of
time, so that applications using OpenSSL (esp. web
servers and clients like curl/wget) have a thing to
discuss and compare vs. e.g. boringssl APIs (which
are IMO understandably more browser-focused); I've
had initial discussions with haproxy and lighttpd
devs that I think have been valuable, so a place for
that that's less ad-hoc and more public seems like
a good plan

- Similarly, a venue for discussion of implementation
details should have value and save time/effort (see
below for examples)

So - whatcha think? I'd be happy to raise this on the
openssl-users list if that's better or to join another
of your calls to discuss (my take fwiw: better if you
folk decide such a list is a good idea, and announce
that list on openssl-users).

Cheers,
S.

[1] https://github.com/openssl/openssl/pull/17172
[2] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
[3] https://github.com/sftcd/openssl/blob/ECH-draft-13c/esnistuff/README.md
[4] https://defo.ie

Examples of implementation things that'd benefit from
list discussion prior to creating a PR after the RFC
pops out:

- My current code creates a "shadow" SSL_CONNECTION on
the client as the client doesn't know which transcript
is needed until it gets the ServerHello; I expect that
you'll hate that:-) (which is ok, I'll probably change
that anyway)

- Extension constructors can have side-effects, which
is a pain but can be handled, but for custom extensions
I've no idea how to handle that, nor how widely used
those may be

- I'm unclear how to distribute code between ssl/ech.c
and ssl/statem/*.c (and a few other similar things) and
it'd likely be a lot easier to handle such comments via
pre-PR mail threads I think

- It may or may not be a good plan to mimic how boringssl
or NSS handle ECH on the client (from the fingerprinting
POV for a n/w observer), and that may change over time; I
bet what I've done there won't be ubiquitously liked:-)

- There are likely many corner-cases of which I'm utterly
unaware that should be handled differently - ECH requires
changes in various bits of the state machine that seem to
overlap with new and older code that's hard to fathom for
me;-)

- I'm still fairly mystified by the perl/TLSProxy stuff
and how it might need to be extended for ECH (I have a
pile of bash scripting to do tests for ECH with HRR/early-
data and other oddities but need help/guidance on how to
make that part of the``make test`` target)

- An eventual ECH PR is going to be >5k LOC I guess, so
it seems reasonable that more than one modus-operandi for
discussion may be needed to do that well without too much
delay


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x5AB2FAF17B172BEA.asc
Type: application/pgp-keys
Size: 5564 bytes
Desc: OpenPGP public key
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20221213/72329f26/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20221213/72329f26/attachment.sig>