Re: [Uta] [Last-Call] Artart last call review of draft-ietf-uta-rfc7525bis-09

[Rob Sayre <[e-mail]>]

On Thu, Jul 14, 2022 at 12:14 PM Peter Saint-Andre <[e-mail]>
wrote:

> > On ESNI in section 3.7. My view is the statement "this information leak
> is
> > closed by use of TLS Encrypted Client Hello." is false. The traffic
> patters to
> > most websites along with IP even when fronted very often reveal exactly
> that
> > information. Often the unencrypted OSCP data on port 80 promptly
> following the
> > ESNI packet reveals more than one would hope. I think there should be
> clear
> > discussion about how using this causes schools in some jurisdictions to
> be
> > legally required to have to install monitoring software on computers
> owned and
> > administered by the student and how this is really bad for privacy.
> There are
> > clear cases where ESNI makes sense, but there are others where the IETF
> in
> > trying to help privacy, is actually making the situation worse.
>
> We could say "you should strongly consider using ESNI when available if
> appropriate for your situation and taking into account all relevant
> considerations described in the ESNI spec" but it seems that the ESNI
> spec ought to be the one that covers this topic in depth.
>

Firstly, it's called ECH now. I believe the draft name is still ESNI so all
of the tools can deal with it (the proposal here gets this right).

I don't think this section is helpful:
https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis#section-3.7

I think it should say something about how connecting to a server
necessarily reveals some information, even if the traffic is encrypted.
That means there is a trade-off between relying on a centralized proxy or
revealing some metadata.

It's not true that SNI is required, TLS often works fine without it. I know
this because I've implemented it incorrectly, and many servers continued to
work. I think it would be fine to document the risks, rather than make
requirements.

thanks,
Rob