Re: HTTPS-RR and ECH

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---39887073-1973702046-1785409791=:601257
Content-Type: text/plain; CHARSET=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <[email protected]>

On Thu, 30 Jul 2026, Michael wrote:

>> We want ECH enabled to push online privacy forward.

> Their proposal assumes that relocating network visibility translates to 
> eliminating it. In reality, Encrypted Client Hello (ECH) merely shifts 
> domain-name exposure from a local internet service provider to a centralized 
> CDN edge—such as Cloudflare.

It's more than a proposal. ECH is defined in RFC 9849. It's live and in use.

It hides the SNI from passive network snoopers. I think that's a good step 
forward.

> i do not agree with c-ares project, so will see imploding it only as a net 
> negative event.

I don't know what that means, but to me that is irrelevant here. c-ares is the 
only way curl can resolve HTTPS records until someone adds support for another 
DNS library, but then I would also love to learn why that other library is 
better for this purpose.

It is up to everyone who builds curl to decide wether to use c-ares or not.

-- 

  / daniel.haxx.se || https://rock-solid.curl.dev
---39887073-1973702046-1785409791=:601257
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

---39887073-1973702046-1785409791=:601257--