On Thu, Jul 14, 2022 at 12:14 PM Peter Saint-Andre <stpeter@xxxxxxxxxx> 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:
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
