Re: [TLS] Working Group Last Call for ECH

[Raghu Saxena <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls