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: Mon, 8 Sep 2025 17:05:39 +0200
Am 08.09.25 um 15:58 schrieb Daniel Stenberg:
> If we cannot verify the resolver somehow, then we cannot trust it but
> we must validate the data ourselves before we rely on information from
> DNS that cannot be verified also using other means. Othwerwise we risk
> leaving users vulnerable.
There's no way I know of to verify a resolver, you either trust it or do
your own validation (again, afaik).
I think it's worth keeping "trust upstream" as an option anyhow, at
least in my use-case the resolver is part of the browser and does dnssec
validation.
> Then we're in agreement!
>
> How can we do validation locally? How do we get the keys necessary to
> verify the data? That seems to be the part that makes this complicated.
>
It's relatively straightforward, just chain validation up to root for
which we have a trust anchor.
We could pull in a stub resolver, I know at least libunbound would work
for this (though I'm not sure about resulting implications, if any).
alternatively we can do the whole thing within curl manually.
P.S. I've updated the proof-of-concept impl to a recent commit, should
be a bit more readable:
<https://github.com/alimpfard/curl/commit/3ba15bac14bf31a0aa71726fa16fad2d940d1e1f#diff-03eaf320162ec20f67fab4e16f494e29735dadfa12425530869d42eea86bd2ccR3736-R3768>
Date: Mon, 8 Sep 2025 17:05:39 +0200
Am 08.09.25 um 15:58 schrieb Daniel Stenberg:
> If we cannot verify the resolver somehow, then we cannot trust it but
> we must validate the data ourselves before we rely on information from
> DNS that cannot be verified also using other means. Othwerwise we risk
> leaving users vulnerable.
There's no way I know of to verify a resolver, you either trust it or do
your own validation (again, afaik).
I think it's worth keeping "trust upstream" as an option anyhow, at
least in my use-case the resolver is part of the browser and does dnssec
validation.
> Then we're in agreement!
>
> How can we do validation locally? How do we get the keys necessary to
> verify the data? That seems to be the part that makes this complicated.
>
It's relatively straightforward, just chain validation up to root for
which we have a trust anchor.
We could pull in a stub resolver, I know at least libunbound would work
for this (though I'm not sure about resulting implications, if any).
alternatively we can do the whole thing within curl manually.
P.S. I've updated the proof-of-concept impl to a recent commit, should
be a bit more readable:
<https://github.com/alimpfard/curl/commit/3ba15bac14bf31a0aa71726fa16fad2d940d1e1f#diff-03eaf320162ec20f67fab4e16f494e29735dadfa12425530869d42eea86bd2ccR3736-R3768>
-- Cheers, ~ Ali Mohammad Pur -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-09-08