Hiya,
On 21/10/2022 00:44, Rob Sayre wrote:
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 isgoing to be deployed prior to its document status.
The above seems correct and apposite.
There’s no point in arguing in the standards work.
That's badly phrased I think. Personally I think there's no point in this thread (other than to ponder the interestingly unidentified OP), but there can well be a point to arguments about ECH (for example, based on having coded it up for haproxy,(*) I'd still like to revisit the HRR and split-mode combo even if it turns out we can't figure out a better way to handle that). Cheers, S. (*) Out of curiosity: has anyone else implemented a split- mode client-facing server that handles HRR?
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
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
