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
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
