On Thu, Jul 14, 2022 at 12:14 PM Peter Saint-Andre <stpe...@stpeter.im> 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
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
