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: ***SPAM**** 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: Stephen Farrell <stephen.farrell_at_cs.tcd.ie>
Date: Wed, 13 Sep 2023 20:25:51 +0100
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 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.
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
>
Received on 2023-09-13
Date: Wed, 13 Sep 2023 20:25:51 +0100
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 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.
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
>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature