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: Thu, 11 Sep 2025 13:23:16 +0200 (CEST)
On Thu, 11 Sep 2025, Timothe Litt via curl-library wrote:
>> If curl doesn't verify the responses itself, how can a user be *sure* the
>> DANE cert they are going to use is the right one?
>>
> The same way that (s)he is *sure* that a non-DANE TLS host is the right
> one. At some point, you trust your configuration.
"Everyone" has a CA store to verify TLS certificates against. And if not, we
fail such attempts by default. DNSSEC is not in the same boat.
> Even if curl were to (correctly) validate responses itself, it would
> ultimately count on the root zone's signing keys.
Yeps. Which is similar in spirit to a CA cert store I think. Magic that has to
be somehow setup.
> Implement the full DNSSEC validation
...
> and serious scope expansion for curl.
There's this magic concept of *libraries* poeple make to provide
functionality. A concept we use quite a lot already. We don't have to
implement everything ourselves.
I don't see how supporting DANE is a "serious scope expansion".
I also don't think supporting DANE in a half-baked insecure way is too
interesting.
> It's not a perfect world. But curl shouldn't take on replicating the
> functions of other available services.
Agreed. But if those other services can't be proven to be trusted, then they
can't be used. So we're back to square one.
Date: Thu, 11 Sep 2025 13:23:16 +0200 (CEST)
On Thu, 11 Sep 2025, Timothe Litt via curl-library wrote:
>> If curl doesn't verify the responses itself, how can a user be *sure* the
>> DANE cert they are going to use is the right one?
>>
> The same way that (s)he is *sure* that a non-DANE TLS host is the right
> one. At some point, you trust your configuration.
"Everyone" has a CA store to verify TLS certificates against. And if not, we
fail such attempts by default. DNSSEC is not in the same boat.
> Even if curl were to (correctly) validate responses itself, it would
> ultimately count on the root zone's signing keys.
Yeps. Which is similar in spirit to a CA cert store I think. Magic that has to
be somehow setup.
> Implement the full DNSSEC validation
...
> and serious scope expansion for curl.
There's this magic concept of *libraries* poeple make to provide
functionality. A concept we use quite a lot already. We don't have to
implement everything ourselves.
I don't see how supporting DANE is a "serious scope expansion".
I also don't think supporting DANE in a half-baked insecure way is too
interesting.
> It's not a perfect world. But curl shouldn't take on replicating the
> functions of other available services.
Agreed. But if those other services can't be proven to be trusted, then they
can't be used. So we're back to square one.
-- / 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-11