Certainly, within the umbrella of "Network Security", privacy is a category. ECH falls into that category.
As with many things in life there is also a trade-off that ECH brings along. More privacy, at possibly less "Network Security" (not a less secure TLS connection), as noted in some of the other emails. Thanks, On Thu, Oct 20, 2022 at 12:14 AM Salz, Rich <rs...@akamai.com> wrote: > > - ECH is not a security feature per se. > > > > The ability of a third party to not be able to see who is communicating is > something that many would consider a security feature. Within the US > infosec community there was a great deal of uproar about NSA data > collection, even if it was “just” (sarcastic airquotes) metadata. Some may > disagree with that assessment, as you apparently do, but please don’t make > definitive statements like the above. > > > > - But yes, what I am talking about is disabling ECH by an > entity/appliance other than the endpoints. One that is authoritative for > the public name, of course > > > > The simplest way for an entity to disable ECH is to not have the DNS > records with the ECH keys. If that means that TLS-inspecting middleboxes > now need to also become DNS servers, many would say that is the cost of > interception. Many would probably also say that’s not a reasonable cost to > impose, but I expect them to be in the minority viewpoint at the IETF. > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
