Are the client facing server to backend server interactions clear enough?

[taddhar]

We need to determine if we are comfortable that the current language regarding how the client facing server and the backend server interact is clear enough.

If not we need to bring it to TLS working group.

[taddhar]

"If these checks succeed, the client-facing server then forwards the ClientHelloInner to the appropriate backend server."

How is this happening, the client-facing server is sending a normal ‘Client Hello’ to the backend server like if it was a normal TLS Client Hello? Or it is still sending the dummy Client Hello Outer AND the Client Hello Inner which is this time in clear?

[taddhar]

The browser does the following: Generate CH_outer Generate CH_inner CH_inner_sealed = seal{CH_inner,AAD} .. where AAD is referring to ClientHelloOuterAAD (see ECH spec), which is just a cryptographic mechanism to link CH_outer to CH_inner for security reasons. “AAD” stands for Additional Authentication Data. .. and “seal" is referring to the output of the HPKE encrypt operation defined at: https://datatracker.ietf.org/doc/html/rfc9180#name-encryption-and-decryption CH_browser = CH_outer + CH_inner_sealed Send CH_browser to the client-facing server

The client-facing server does the following: Receive CH_browser Extract CH_outer and CH_inner_sealed from CH_browser Calculate AAD from CH_outer CH_inner = open{CH_inner_sealed,AAD} .. where “open” is referring to the HPKE decrypt+authenticate operation (see earlier link) Send CH_inner to final destination

[taddhar]

Arnaud to check the ECH draft itself

[taddhar]

The draft specifies certain things but some CDNs may implement somethings. See with @PascalPaisant @zied-turki and @roelfdutoit. it would worth resurrecting emails on the topic to see if it worth updating our draft.