On Tue, Mar 12, 2024 at 10:20 PM Raghu Saxena <poiasdpoi...@live.com> wrote: > > Are comments restricted strictly to members of the working group? If so, > please ignore this E-Mail. > > I'd previously tried to raise an issue regarding requirements of a > public_name in the ECHConfig in the mailing list [0], and when I didn't > get much response there, even on Github [1], where I was further met by > silence. I assumed this meant since I am not in the working group I am > not allowed to participate in discussions, but seeing the "Last Call" I > thought I'd try one last time.
Please read https://www.ietf.org/about/introduction/. To put it shortly there is no such thing as WG membership beyond participation. > > My concern relies around the fact that by requiring a public_name in the > ECHConfig, and clients "SHOULD" pass it, means we are losing basically > all the benefit we initially had with ESNI, since now some part is > leaked anyway. This was not an issue in original ESNI. Although the > draft allows for a client to not use this value, and/or for a server to > not validate it ("SHOULD" rather than "MUST"), in practice all of the > most popular clients (i.e. browsers) will probably end up using / > sending it. We saw this for SNI, where even websites which don't need it > (e.g. a very popular adult website), browsers will still send it, and > this becomes a vector for censorship / blocking. The reason the public_name exists is so that the connections can all have the same SNI field. Since we can't do what ESNI did, there must be something there and it should all be the same. > > If this requirement is unlikely to change, my question then becomes - it > is "acceptable", as a website operator who does not wish to leak the > domain name in the ECHOuter's plaintext SNI, to specify the > "public_name" in the ECHConfig as something random (e.g. "example.com"), > acknowledging the fact that as a server operator, I will disregard any > value the client passes for the SNI in the ClientHello anyway? Or is > there another recommended approach if I do not want the actual domain to > be leaked on the wire. This is coming as an individual operator, with no > CDNs to hide behind (e.g. `cloudflare-ech.com`). I'm not sure what problem you want us to solve here. In the case of server offering a single domain, an attacker can determine that connections to that domain go to the server and cheaply block based on IP. As a result the threat model is one of distinguishing between connections to two different inner names. > > Lastly, I also struggle to understand the value of this field. From > reading the RFC, it seems it is mostly only applicable if the server > rejects ECH. I would think this happens if the server does not support > ECH, and therefore should not have had an ECHConfig published anyway- or > the client is unable to satsify the server's ECH requirements. In both > cases, I would think it is on the client to fallback an purposely > initiate a non-ECH TLS handshake, rather than "downgrade" the > connection. Forgive me if I am missing something obvious, but as someone > who used ESNI successfully back when it was in draft status, and was > happy with no SNI being leaked, I am unhappy that it has returned. DNS does not propagate atomically with webserver configuration changes. It's thus necessary to deal with mismatches. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
