davidben
commented
3 years ago 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.)
Closes #474. 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.