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: Ali Mohammad Pur via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 7 Sep 2025 21:38:27 +0200
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 :)
Date: Sun, 7 Sep 2025 21:38:27 +0200
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.htmlReceived on 2025-09-07