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 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.
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?
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.
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).
--
/ daniel.haxx.se || https://rock-solid.curl.dev
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
