On 13/09/2023 13:24, Daniel Stenberg wrote:
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.
Fair enough, we'll concentrate on the using-DoH scenario for now, and hope someone else does work to add HTTPS RR support to c-ares in the meantime:-) One other note below:
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 RRsThis 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.
Taking that approach might in some cases increase the risk of a mismatch between A/AAAA and an HTTPS RR value, if those do have multiple values, with mismatching ones cached on the two "resolution paths." That's been a concern with the ECH design from almost the start, even though nobody seems to quite know how much of a risk it represents. (Or even how to try measure that risk;-) That's another credible reason to prefer sending both A/AAAA and HTTPS queries over the same DoH session - the theory is it may reduce such risks. Cheers, S.
[*] = https://github.com/curl/curl/discussions/11125
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
