* 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
