Hiya,
Wasn't sure which email to reply to, but this one'll do... Until very recently I was of the opinion that ECH split-mode when one hits HRR with our current design was significantly problematic. The main reason was that supporting that scenario with haproxy seemed like it'd require significant change to the application, as haproxy is basically designed to only look at the first ClientHello message when acting as a frontend that doesn't terminate the TLS session, but just routes sessions based on the first ClientHello SNI. (Doing ECH decryption on the 1st ClientHello was ok, but getting at the 2nd one with all the right state was the problem due to how the application code was architected.) With some more delving into things, I've managed to find a relatively doable (if slightly iccky) way to support ECH split-mode+HRR in both haproxy and nginx, so I think we can strike this as an objection to the current design. This likely affects a few of the issues in github, (in a good way:-) but I didn't comment on those as it doesn't quite fit any of 'em exactly. It should in any case help as the editors set out to close issues, My proof-of-concept code for nginx [1] and haproxy [2] is available and if anyone's interested in details I'm happy to point out specifics. (Note that that code is far from production-ready but I think it's good enough to show support is possible without that much change.) Cheers, S. [1] https://github.com/sftcd/nginx/tree/ECH-experimental [2] https://github.com/sftcd/haproxy/tree/ECH-experimental On 03/06/2021 22:03, Christopher Wood wrote:
Hi folks,Since the last IETF meeting, the HRR Design Team has worked through the issue of dealing with HRR. A writeup of the team's efforts, discussions, and recommendations is here:https://github.com/tlswg/draft-ietf-tls-esni/wiki/HRR-Design-Team We believe next steps are to merge the following PRs:- https://github.com/tlswg/draft-ietf-tls-esni/pull/423 - https://github.com/tlswg/draft-ietf-tls-esni/pull/422To that end, we would appreciate additional review. Hearing no objections, we'll plan to merge these at the end of next week and close out the relevant issues.Thanks, all! Best, Chris_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
