Original text:
8.2. <del> A more serious problem is MITM proxies which do not support this extension.  RFC8446, Section 9.3 requires that such proxies remove any extensions they do not understand.  The handshake will then present a certificate based on the public name, without echoing the "encrypted_client_hello" extension to the client. </del>  Depending on whether the client is configured to accept the proxy's certificate as authoritative for the public name, this may trigger connection failure.  A proxy which is not authoritative for the public name cannot forge a signal to disable ECH. <del> A non-conformant MITM proxy which instead forwards the ECH extension, substituting its own KeyShare value, will result in the client-facing server recognizing the key, but failing to decrypt the SNI.  This causes a hard failure.  Clients SHOULD NOT attempt to repair the connection in this case. </del> 9. In the absence of an application profile standard specifying

Reviewer comments:
This makes a few changes to the middlebox section: First, using "MITM proxies" when RFC8446 talks about terminating TLS was confusing, so align with the RFC8446 terminology. Next, RFC8446 does not quite require dropping unknown extensions, only generating your own ClientHello. Dropping unknown extensions happens if the proxy tries to intersect its true capabilities with that of the client. I've also dropped the "a more serious problem" introduction since the point of this section is that it's not a serious problem. Finally, I've dropped the "non-conformant MITM proxy" paragraph. It's slightly out of date now that we've unified everything around trial decryption. I believe, depending on what the proxy does with the server's EncryptedExtensions response, things will either break, work on accident, or retry loop and hit the limit. It doesn't seem worth expending a whole lot of text on something that is the proxy's fault. This does drop the "Clients SHOULD NOT attempt to repair the connection in this case" line, but the client couldn't really detect this case anyway. It looks like any old connection failure without a proxy, and the usual considerations for changing your TLS config on connection failure apply.
Ah good point. I dropped the "which do not support this extension" clause on accident. How's this new iteration? (Seems best not to get into middleboxes which do support the extension. "which likely means being involved in" feels too handwaivy, and I'd rather not expend a lot of text around how DNS works with HTTP CONNECT proxies, CDNs where the "proxy" is on the server's side and controls DNS, etc.)
Hello, While reading this specification, section 8.2. states that "MITM proxies" are required to remove any extensions they do not understand. extension. [RFC8446], Section 9.3 requires that such proxies remove any extensions they do not understand. The handshake will then present a certificate based on the public name, without echoing the "encryptedclienthello" extension to the client. However, looking at RFC 8446 Section 9.3, the first section you encounter on forwarding middleboxes explicitly states the opposite: the middlebox is not allowed to change or modify any parameters in the handshake and subsequent traffic if it doesn't understand some parameter in the ClientHello: understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified. Otherwise, it may fail to interoperate with newer clients and servers. Reading further, we find the bullet point the warning in section 8.2 refers to: compliant TLS server (to the original client), including having a certificate which the client is willing to accept, and also as a compliant TLS client (to the original server), including verifying the original server's certificate. In particular, it MUST generate its own ClientHello containing only parameters it understands, and it MUST generate a fresh ServerHello random value, rather than forwarding the endpoint's value. Here, the middlebox isn't so much required to "remove any extension they do not understand", but to "generate its own ClientHello containing only parameters it understands". After carefully reading over these sections multiple times, I do get the message, but I feel like it could be better worded as not to create confusion. The words "MITM proxy" could refer to the forwarding middlebox as well. Changing the wording in, for example, the following way makes the reference more clear in my opinion: extension. [RFC8446], Section 9.3 requires that such proxies generate their own ClientHello containing only parameters they understand. The middlebox will then present a certificate based on the public name to the client, without echoing the "encryptedclienthello" extension. What do you think about this?
Yes. Or, more accurately, it's required to send a ClientHello only containing things it supports. Whether it choses to base its capabilities on the original ClientHello is its business. Though, of course, there are security implications for either option and more reason why MITM proxies are a terrible idea. Either way, if you are a MITM proxy, you are terminating TLS, which means there are two TLS handshakes and, in one of them, you are a client. When acting as a client, you cannot send things you don't understand. Otherwise the server will respond in a way that confuses you. RFC 8446 does not discuss "forwarding middleboxes" at all. That section talks about a "middlebox which forwards ClientHello parameters it does not understand". Any middlebox that does this cannot terminate TLS in the first place (i.e. not a MITM proxy) because anyone terminating TLS is limited to only sending things it understands. Rather, this section is talking about non-terminating proxies that attempt to inspect the cleartext portions of TLS anyway. We ran into quite a lot of those in the process of deploying TLS 1.3 and most of them were broken. This text clarifies that TLS promises no continuity of syntax after the ClientHello. A non-terminating proxy gets to assume it can parse the ClientHello and nothing else. See above. If you're forwarding things you understand, you cannot terminate TLS. The section doesn't apply to what this draft refers to as "MITM proxy" at all. (Well, there are some weird things that try to selectively proxy TLS. There are with this approach, but in that case which rules apply depends on which choice the proxy made. Additionally, the proxy cannot violate the forwarding middlebox rule in the process of making the decision. This basically boils down to saying you cannot make your decision based on anything after the ClientHello because, after that point, you cannot parse anything.) Probably we should change this draft to match RFC 8446 in terminology and replace "MITM proxies" with "TLS-terminating proxies". Yeah, I think that change is a good one.
Thank you for your detailed reply. I do understand the reasons for being this strict about middlebox behaviour. I certainly don't think there is anything wrong. It's just that the terminology is somewhat confusing. After careful reading, it's indeed clear that the section on non-terminating proxies is not really relevant for ESNI, but due to the wording used in this RFC, it looks at first glance that 8.2 is referring to that section: vs It's a small detail, and not really that important. But I think it would make it more clear if the wording is changed slightly. I do like "TLS-terminating proxies" as well. Thanks for the hard work!
How does URL look?
Looks good to me! Thank you for taking the time to look at this.
The middlebox could also support ECH, right? It would need a way to get a config, and probably would need to be involved in feeding a config too the client, but it is at least possible for interception to consume and use ECH. Maybe qualify with "unless the middlebox understands ECH and is able to interpret the extension (which likely means being involved in providing the client with an ECHConfig)..."

Revised text:
8.2.  <ins> When connecting through a TLS-terminating proxy that does not support this extension, RFC8446, Section 9.3 requires the proxy still act as a conforming TLS client and server.  The proxy must ignore unknown parameters, and generate its own ClientHello containing only parameters it understands.  Thus, when presenting a certificate to the client or sending a ClientHello to the server, the proxy will act as if connecting to the public name, without echoing the "encrypted_client_hello" extension. </ins> Depending on whether the client is configured to accept the proxy's certificate as authoritative for the public name, this may trigger connection failure.  A proxy which is not authoritative for the public name cannot forge a signal to disable ECH.  9. In the absence of an application profile standard specifying