[ech] heading towards a PR for ECH

[Stephen Farrell]

Hiya,

The ECH branch [1] we have seems functional and hopefully the IETF spec
is heading towards being done. To date, there's no indication that
protocol changes that'd affect interop seem likely in the near
future and there's an announced intention to handle the official/final
TLS extension codepoints(*) in a way that'd be good to handle in
terms of making a PR soon.

So, all that going well, my non-secret plan is to tidy up a few
things(**) and to create a PR for ECH in the coming weeks. It's fine
if that takes some time for the project to digest (there's a *lot*
of widely distributed code changes, that I can't see a good way to
separate into multiple PRs sensibly, so I'm sure it'll be fun:-),
but I figure better to get started down the processing-the-PR road
with the optimistic goal that the RFC issues about the time the
PR seems ready to merge. (Again optimistically, that'd be in early
2024.)

In terms of other "upstreams", I've also got a PR for curl [2] that
works with my branch or with boringssl or (mostly) with wolfssl that
I hope to get merged to their ``master`` branch (as an experimental
feature) early in the new year, and plan to follow that up with similar
upstream PRs for nginx, apache, haproxy and lighttpd.

So, given that processing an ECH PR will likely consume some cycles
for project folk, I figured it'd be good to give a heads-up that
that's my current plan. If there are reasons to do something else,
e.g., to first do another call to chat about APIs or about
implementation internals, I'm very happy to do that, but if that's
something we could get done in the coming month or so, that'd be
great.

In other news, as part of the DEfO project [3] we've made some
packages (openssl & nginx) for debian unstable that we hope will
make it easier for people to try out ECH in the short term, while
upstreaming code is in the works. There's an evolving HOWTO [4]
we're hoping might help people play with that stuff so if any of
you are motivated to try it out that way, feedback is most
welcome. ([4] has only been tried out twice so far, so early days
and all that:-)

For local reasons (ahem, funding:-), it'd be good for me if I
created a PR (or draft-PR if that makes a difference) before the
end of Nov. But not that big a deal if that slips to Dec and I'm
fine that those local reasons aren't compelling for the project,
nor should they be.

Lastly, I've so far done nothing at all to consider ECH+QUIC. (I've
also done nothing to try make that harder though.) If that's a thing
that needs chatting about now, then be great to know that, but my
assumption is that it's worthwhile progressing a PR for ECH+TLS/TCP
first, before turning attention to ECH+QUIC.

Cheers,
S.

[1] https://github.com/sftcd/openssl/tree/ECH-draft-13c
[2] https://github.com/sftcd/curl/tree/ECH-experimental
[3] https://defo.ie/
[4]
https://gitlab.com/jspricke/info/-/blob/blog-ech-setup/conten/blog/2023-10-30-ech-setup.md

(*) As the drafts for ECH have evolved, we've been incrementing
the TLS extension codepoints to preserve interop, so the current
ECH TLS extension codepoint (0xfe0d), is picked from an experimental
range. The plan as of now, is not to change to a new codepoint for
the final version, but to assign the previously experimental ones
as the official/final codepoints. That's nice in that if it happens
as planned, it'll avoid the need for a flag-day or transition for
current code/deployments.

(**) There are a few ways in which the branch needs to be changed
before or during the processing of the PR, e.g., likely integrating
what's currently in ``include/openssl/ech.h`` into ``ssl.h`` so I'll
do an edit/test pass like that before creating a PR. I think there's
only one functional addition still required (addition of a way to
GREASE retry_config values), the rest of the work to create the
PR (that'll undoubted change lots as we go) should be pretty much just
build/git stuff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE4D8E9F997A833DD.asc
Type: application/pgp-keys
Size: 1197 bytes
Desc: OpenPGP public key
URL: <https://mta.openssl.org/pipermail/ech/attachments/20231103/38213e9f/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/ech/attachments/20231103/38213e9f/attachment.sig>