Hi, In the split mode of the current draft of ECH, both the client-facing server and the backend server are needed to be ECH-aware. As upon the client-facing server decrypted the ClientHelloOut, it will forward the ClientHelloInner to the backend server, and waiting the backend's ServerHello with random embed with the accept_confirmation.
If you want to deploy ECH, you have to upgrade both the client-facing server and the backend server. However, it is not an easy task to upgrade all the backend server in one day. So I am wondering if it is possible to adjust the design to allow the deployment without altering the backend server. Suppose we use the following topology: browser <-----> ECH-aware Client-facing server <------> normal TLS backend server For any TLS backend server, for example, https://example.com, We only upgrade the browser and the client-facing server. The browser fetch the ECH config from DNS, and encrypt the ClientHello according the current draft design. The client-facing decrypt the ClientHelloInner and use it as the normal ClientHello to do the TLS handshake to the normal TLS backend server without any ECH extension. Upon the normal TLS backend server receive the decrypted ClientHello, it response the normal ServerHello to the client-facing server. After receiving the ServerHello from the backend server, the client-facing server need to response the accept_confirmation to the browser. This is the design changes I propose to change. Because the current draft requires the backed server generate the accept_confirmation bytes and embed it into the random of ServerHello, which can not be changed by the client-facing server. In order to support ECH for normal existing TLS server, we may let the client-facing response the accept_confirmation on behalf of the backend server, which means we can not use the random field of ServerHello to store the accept_confirmation, because changing it will abort the TLS handshake. So is it possible to transfer the accept_confirmation in some plain text extensions like Key Share, or other dedicated extension? If it is possible, we can deploy ECH by only upgrading the browser and client-facing server without require change all the existing backend server. This idea was derived from my attempt to implement encrypted TLS SNI Proxy. The SNI does not only expose privacy information, many ISP use it to block certain web site. Even though the current draft of ECH works to protect the ClientHello, it can only protect the sites that deployed the ECH. If we can adjust the current design and let the client-facing generate and response the accept_confirmation signal, we can make ECH everywhere without upgrading any of current TLS backend server. Which means the client-facing can work as an encrypted TLS SNI Proxy. Please consider my proposal and give your comments Thanks. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
