I have risen similar discussion before and have tried to suggest some solutions, but none of them got any support.
Here is the previous discuss thread, just FYI https://mailarchive.ietf.org/arch/msg/tls/HlwYX16Y4W2BevKTpI6a81eO1JE/ > On Mar 13, 2024, at 13:20, 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. > > 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. > > 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`). > > 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. > > Regards, > > Raghu Saxena > > [0] https://mailarchive.ietf.org/arch/msg/tls/HUG1CU0Q4PorZ7fD0yafVfj7VUY/ > > [1] > https://github.com/tlswg/draft-ietf-tls-esni/issues/572#issuecomment-1780859252 > > On 3/12/24 06:00, Joseph Salowey wrote: >> This is the working group last call for TLS Encrypted Client Hello [1]. >> Please indicate if you think the draft is ready to progress to the IESG and >> send any comments to the list by 31 March 2024. The comments sent by Watson >> Ladd to the list [2] on 17 February 2024 will be considered last call >> comments. >> >> Thanks, >> >> Joe, Deirdre, and Sean >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ >> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/ >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > <OpenPGP_0xA1E21ED06A67D28A.asc>_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
