Buy commercial curl support. 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 Daniel himself.
Re: Using/validating DANE certs?
- 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: Sat, 6 Sep 2025 23:40:11 +0200 (CEST)
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).
Date: Sat, 6 Sep 2025 23:40:11 +0200 (CEST)
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.htmlReceived on 2025-09-06