> On Aug 24, 2022, at 16:11, Eric Rescorla <e...@rtfm.com> wrote: > > As a practical matter, most sites need to be deployed on cloud services like > AWS, Cloudflare, etc., so if this is true, > then ECH just isn't going to work at all. But, I don't think it's in fact > going to be the case in many jurisdictions.
I am not saying ECH isn't going to work at all. Even most sites need to be deployed behind cloud services, it not means we could design a standard to make it as a requirement. > >> If we can deploy the ECH without the public_name, all website, whether join >> a pool or not, could deploy ECH. And the censors cannot >> easily block one site by its name. What the censors can only do is fetching >> the A/AAAA record periodically and block that IP addresses. > > Sites can do this right now by simply using a common invalid public_name, > e.g., "esni.invalid" > >> And the server can easy change to the new IP addresses. > > Why do you believe this to be the case? It's not clear to me that this is so. But why not? Some IP address has been blocked, and choose another one. It is simple and natural. > >> And recall why the outer public_name is required? It is used to "correct" >> the browsers' outdated ECHConfig. This feature can be accomplished by several >> different ways, including DNSSEC or public some signing key by DNS. So why >> we insist to use the outer TLS handshake? > > It's not clear to me what you have in mind here, so I can't tell whether > these are real alternatives I have try to make my opinion clear as far as I could. If you follow all the mail in this thread, I wish you could get my idea. But if you finished all the thread and still confusing, I am sorry for my expressive ability, because I am not a native English speaker. > The setting in which the outer public_name is useful is the one in which the > ECHConfig key is wrong but the ECHConfig public_name is correct, presumably, > as you say, because DNS is out of date. How do you think DNSSEC fixes this > problem? Why ECHConfig could be wrong? Because we choose to rotate them frequently. In contrast, the DNSKEY using in DNSSEC do not need to change as frequent as ECHConfig rotated. So when the ECHConfig outed, the DNSKEY does not. Maybe the DNSKEY do be outed. We can response all the HTTPS/RRSign/DNSKEY records from the server side. And the client just fetch other records for upper lever domain(maybe top level domain) only, which will be changed more slowly.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
