Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: ECH support (when curl is not using DoH)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 13 Sep 2023 14:24:42 +0200 (CEST)
On Wed, 13 Sep 2023, Stephen Farrell via curl-library wrote:
> There should be a use-case for ECH when DoH is not used by curl - if a
> system stub resolver supports DoT or DoH, then, considering only ECH and the
> network threat model, it would make sense for curl to support ECH without
> curl itself using DoH.
Yes, I am sure there will be users craving for this. I am of course fine with
doing that in a "second wave" or something though. No need to do everything at
once.
This is similar in spirit to the people who are asking (I'm being polite so I
do not write "demanding" here) for an option to disable the .onion filtering
[*] because they run a setup where they are in full control of the resolver
and they know it is fine.
> One option would seem to be to extend the c-ares library to support HTTPS
> RRs
This is the route I have been pondering myself. I am a co-maintainer of c-ares
and I think it would fit in the library so I don't think such an extention
would face any problems there.
Adding another separate DNS library seems a little unfortunate since we
already use c-ares for other things and replacing c-ares completely feels like
quite a lot of work...
A little extra "quirk" is of course that currently when curl is built to use
c-ares, it *replaces* the normal resolver lookups and only c-ares is used, but
it might be that we to allow the stock resolver for regular A/AAAA lookups and
only use c-ares for HTTPS. This, because it turns out that replacing the stock
resolver for these name resolves is darn next impossible for all of the
never-ending edge cases out there in the world.
[*] = https://github.com/curl/curl/discussions/11125
Date: Wed, 13 Sep 2023 14:24:42 +0200 (CEST)
On Wed, 13 Sep 2023, Stephen Farrell via curl-library wrote:
> There should be a use-case for ECH when DoH is not used by curl - if a
> system stub resolver supports DoT or DoH, then, considering only ECH and the
> network threat model, it would make sense for curl to support ECH without
> curl itself using DoH.
Yes, I am sure there will be users craving for this. I am of course fine with
doing that in a "second wave" or something though. No need to do everything at
once.
This is similar in spirit to the people who are asking (I'm being polite so I
do not write "demanding" here) for an option to disable the .onion filtering
[*] because they run a setup where they are in full control of the resolver
and they know it is fine.
> One option would seem to be to extend the c-ares library to support HTTPS
> RRs
This is the route I have been pondering myself. I am a co-maintainer of c-ares
and I think it would fit in the library so I don't think such an extention
would face any problems there.
Adding another separate DNS library seems a little unfortunate since we
already use c-ares for other things and replacing c-ares completely feels like
quite a lot of work...
A little extra "quirk" is of course that currently when curl is built to use
c-ares, it *replaces* the normal resolver lookups and only c-ares is used, but
it might be that we to allow the stock resolver for regular A/AAAA lookups and
only use c-ares for HTTPS. This, because it turns out that replacing the stock
resolver for these name resolves is darn next impossible for all of the
never-ending edge cases out there in the world.
[*] = https://github.com/curl/curl/discussions/11125
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-09-13