Hi, Rob, Also CC Stephen,
I am not make my opinion clear, sorry for disturbing. And I try my best to summary my opinion again. If people want to deploy ECH, they need to public the ECHConfig by the HTTPS/SVCB DNS record. The browser use the ECHConfig to encrypted the inner client hello data, and send it to server by an out client hello message. In order to minimize the risk of leaking private data of ECHConfig, the ECHConfig should be rotated periodically. As a result, the browser may use the outdated ECHConfig. In order to "correct" those browser with outed ECHConfig, the server needs to reply the latest ECHConfig. But how could the browser confirm the ECHConfig replied by the server is the correct one? This is why the outer SNI, domain name, and certificated are needed. In this occasion, the server use the certificate indicated by the outer SNI to handshake with the browser, and response the new ECHConfig with server encrypted extension. By the server encrypted extension, the client can verify the ECHConfig server respond is valid, so the client could update their local cache. What I try to accomplish is to drop the dependence to the outer SNI/domain name. But why? Because if small websites do not behind some common intermediary, which domain could it offered for the outer SNI? As Stephen mentioned two cases, > A small hoster can choose a > "public_name" and use that for customers. An enterprise of > whatever size can choose a "public_name" like example.com > <http://example.com/> and > then use that and ECH to cover accesses to other internal names like > accounts.example.com <http://accounts.example.com/> or hr.example.com > <http://hr.example.com/>. In the first one, these small sites may deploy be deployed to some small hoster or big one like Cloudflare. So the hoster will offer the common "public_name" for the outer SNI. In the second, they can chose some some subdomain as the "public_name" like example.com <http://example.com/> to protect their internal names like hr.example.com <http://hr.example.com/>. The second case will expose the example.com <http://example.com/>, which is, in my own opinion, as sensitive as the internal one. Because when some website has been blocked, their whole domain has been blocked as well. Use the apex domain to protect the inner domain is useless. The first case works technically, but it is not suit for sites who deployed in a simple VPS or even home server. What I try to accomplish is to let every website could deploy ECH. And recall why the outer SNI is needed? Only because the browser need to confirm the updated ECHConfig offered by the server is valid. In my opinion, there are different ways to accomplish this feature without the outer TLS handshake. One of them is use DNSSEC. The sever just respond the correct HTTPS RR with its responding SIGRR, and the browser could verify them. However, this way requires the browser to implement DNSSEC verify process, which is not an easy task to make consensus. Another one is publish another public key by DNS to check the signature of the updated ECHConfig offered by server. As this key is only used for ECHConfig updating process, there is no need to rotate it very frequently. This idea requires the browser to implement one small additional signature verification, which is far more simple than the DNSSEC. By the way, the current design of ECH is good for hosters like Cloudflare. Because they already have the intermediary proxy. Wish I have made me understood. If I offend some one, I am sorry. > On Aug 24, 2022, at 09:33, Rob Sayre <say...@gmail.com> wrote: > > The design does not work without what the draft calls an "anonymity set". > Maybe you could explain your threat model a bit more? > > For example, if every domain had an IPv6 address, encrypting the SNI wouldn't > conceal any information. > > I have no idea what you're trying to accomplish here, >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
