Dear Dennis, 涛叔, On 10/9/23 09:21, 涛叔 wrote:
We can change IP freely, but it is hard, if not impossible, to change domain name.For indie web server, they can buy two domains, one for their brand, and the other for ECH. If the public name has been blocked, they have to buy another one. But if we allow the usage of pseudo-domain, this problem will disappear.
Agreed, for personal use, it is surprisingly easy to "rotate IPs", e.g. just kill and spin up a new VPS, would usually result in a new IPv4 on most providers. Sure, it may take some time for new DNS records to propagate, but ultimately the "end-users" who are familiar with the domain can continue to access the website.
I would describe ECH primarily as a technology for improving privacy. Unfortunately, I don't think it's any kind of silver bullet for censorship resistance.Improving privacy imply censorship resistance. Although censorship resistance is not the goal, we should not deliberately design *required* features which will make the censorship easy.
I also agree. For large providers like cloudflare, who's business model is basically TLS interception, it is easy to hide their customers behind their single front (`cloudflare-ech.com`). However, for individuals, this now means the need to rely on such services. In fact, Stephen Farrell (who I believe is on this mailing list) highlights in his lecture slides that ECH may lead to more centralization, with the "big players" such as Cloudflare / Google being the main beneficiaries (Slide 30, https://down.dsg.cs.tcd.ie/cs7053/lectures/13-ech.pdf)
BTW, if we public ECHConfig using a domain name which we do not own SSL certificate, it does not make thing worse. Because when the client needs to re-sync the ECHConfig, the SSL handshake will fail due to the invalid certificate. However, I prefer to make this behavior clear in the RFC.
Explicitly adding it in the RFC would be beneficial, so that we don't need workarounds such as a fake domain in the public name field, which most likely would mean TLS verification failures in most clients that implement it. Instead, the behavior should be to "abandon" the connection if it is not possible, based on the servers ECHConfig, instead of trying a less secure connection automatically, i.e. without ECH. For instance, HSTS (RFC6797) is purely server telling the client how to behave if it can't verify the certificate. Of course the client may ignore it, but at least the defined behavior is "more secure".
Regards, Raghu Saxena
OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
