[ech] heading towards a PR for ECH

[Matt Caswell]

On 03/11/2023 01:55, Stephen Farrell wrote:
> 
> 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.)
> 

Thanks for the update Stephen.

> 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.

Yeah, lets not worry about ECH+QUIC just yet.

Matt


> 
> 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.
>