I think the WG might want to consider how it spends its time. The ECH draft has been adopted as a work item. In case it’s not obvious, this one is going to be deployed prior to its document status. There’s no point in arguing in the standards work.
thanks, Rob On Thu, Oct 20, 2022 at 11:48 Safe Browsing <safebrowsing...@gmail.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
