* Client <-> Middlebox <-> Client-facing server <-> Backend server
* With "Middlebox" really meaning a middlebox like a firewall or similar. The middlebox is not allowed to modify traffic between the client and the server. Doing so would mean that the packets the client sent are not the ones that the server received, and the two message digests would disagree. (If you think about things, it *has* to be this way, otherwise TLS would not be able to provide integrity guarantees.) * From the draft, ECH seems to be designed to still allow successful TLS connection establishment if the encrypted_client_hello extension is dropped from the ClientHello on a conforming middlebox. Provided that the middlebox is authoritative for the client-facing server's public name, as reported/delivered by DNS to the client. We can assume that this is the case here. I do not understand what you mean by this. The word “authoritative” is used to mean that it has a certificate and keypair and can do TLS termination. DNS giving the client a particular IP address is not authoritative. It can be confusing because DNS terminology uses authoritative to mean that a particular entity can prepare data used for DNS responses. But it is not authoritative in the TLS sense. I think your questions can be answered with those two overall corrections above. If not, please continue the thread. (And feel free to repost from your note since I trimmed for brevity.)
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
