On 06.09.2025 23:40, Daniel Stenberg wrote:
On Tue, 2 Sep 2025, Ali Mohammad Pur wrote:
How would curl figure out that it works with a resolver that
verifies DNSSEC?
My suggestion was to assume so and not think about it except in cases
where curl is doing the resolution manually. IIRC Niall called it a
"hand of God" approach to getting the records :P
If we would accept that, how would random users running curl know that
the HTTPS connection is secure when they use DANE? That is after all
what the URL scheme implies and I believe it is our job to make sure
it is.
I think this boils down to answering "what parts of the larger system
that we're running on do we trust?", we currently trust (at least) the
certificate store, but not the resolver; we can trust the resolver, or
do our own DNSSEC validation locally - no other possible way.
I would find it embarassingly weak to say "it depend on your resolver"
and leave users possibly vulnerable to MITM attacks. And not even a
theoretically fringe minority: a really large chunk of the users.
If a user doesn't trust their resolver, maybe they should not be using
it? I do understand that my suggestion expands the trust base, however.
Another option could be to simply not expose this as a switch to users
at all (i.e. don't do any resolution, but use the records if they're
available), not exactly a good option but it would work for my use-case
nonetheless.
How is that different from just providing a CACERT bundle in a
dedicated file?
That would only be possible with DANE-TA, also the PKIX-* modes would
require both DANE and CA validation to accept the connection.
Sorry, the different modes make me confused. Which mode would you say
is the one users would like or perhaps is the most interesting to
implement support for?
Most users on the web would most likely be using DANE-EE, you get a hash
for the expected certificate and accept if it matches (no CAs or chains
involved). DANE-TA could show up in corporate settings still, ofc.
Still, I wouldn't put the number of people running local stubs with
dnssec validation enabled so low, systemd-resolved supports dnssec
and it seems to be enabled on my system without me explicitly
enabling it (n=3, so probably needs more investigation).
I don't think the exact ratio is terribly important. I'm convinced the
amount of users not running a DNSSEC secured local resolver is of a
size that is large enough to care about. I think we need to either
verify the DANE responses or at worst reject them because they can't
be trusted.
That's reasonable, I'd be in favour of verifying DNSSEC locally for all
cases even (sadly not very viable though, a big chunk of the open web
would fail validation).
Perhaps not, though there are things that curl may want to care about
(ECH, HTTPS RR, and TLSA for DANE).
Sure. curl already features (experimental) support for HTTPS-RR (and
ECH).
Right, exactly why I mentioned them :)
--
Cheers,
~ Ali Mohammad Pur
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
