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, 01 Sep 2025 16:11:25 +0200
> This is surprising to me. What data are you basing this statement on [...]?
Nothing particularly concrete, but I've heard a bunch about wanting to forego "normal" CA certs for DANE-EE. Re browsers, I know of at least one extension that tries to verify DANE[1].
> getting the DNSSEC stuff done correctly with the all the keys etc to verify that the records we get are legitimate for the domain.
Yeah I'm personally proposing that curl shouldn't concern itself with this, asking the user to use a resolver that verifies DNSSEC is fairly reasonable to me.
In the case of the ad-hoc DoH resolver for ECH (and c-ares), it's probably best to "just" enable dnssec validation or fail the request entirely if not available/possible.
> Maybe you can start easy by explaining the libcurl API you have envisioned for this, and what actions that would trigger?
Sure, if we go the route of my proof-of-concept, the user would have to provide the TLSA/DANE records (wirefmt base64'd) via some CURLOPT[2]; a nicer extension could have libcurl do the resolution itself if requested, trusting the underlying resolver for DNSSEC validation.
Alternatively I can see an API that would take the records as parsed fields, but I think it's worth having more "generic" RR support - I know at least MX is/was being discussed at some point.
> It looks like you use c-ares for the DNS record fiddling, right?
Right, for ease of implementation really, though parsing that particular record type isn't _too much_ work in isolation.
[1]: <https://addons.mozilla.org/en-US/firefox/addon/dnssec-dane-padlock>
[2]: <https://github.com/alimpfard/ladybird/blob/d82765d82bbb823a0d56f75b9a13180bd5dd383c/Services/RequestServer/ConnectionFromClient.cpp#L446>
Am 1. September 2025 15:53:41 MESZ schrieb Daniel Stenberg <daniel_at_haxx.se>:
>On Mon, 1 Sep 2025, Ali Mohammad Pur Fard via curl-library wrote:
>
>Thanks for your interest and willingness to help improving curl!
>
>> Since DANE/TLSA has become much more common as a replacement for PKI
>
>This is surprising to me. What data are you basing this statement on and what PKI do you speak of here? The popular browsers don't support DANE, so deploying it for the web seems like a lot of work for a rather small audience.
>
>> In particular, I'm mostly interested in having libcurl expose a way for users to provide (or request the use of) a set of TLSA records, or somehow communicate that DANE should be used for the connection (as I'm trying to have DANE be a native alternative to PKI in Ladybird[1]). The request side of this is reasonably straightforward with openssl, at least.
>
>We added "Support DANE" to the TODO document already in August 2012. I think it would be cool to get support in and I know there is at least some interest "out there".
>
>We once had an attempt and I recall that we then had some challenges on getting the DNSSEC stuff done correctly with the all the keys etc to verify that the records we get are legitimate for the domain.
>
>> I do have a patchset[2] that implements this as a proof of concept
>
>Maybe you can start easy by explaining the libcurl API you have envisioned for this, and what actions that would trigger?
>
>It looks like you use c-ares for the DNS record fiddling, right?
>
>--
>
> / daniel.haxx.se || https://rock-solid.curl.dev
Date: Mon, 01 Sep 2025 16:11:25 +0200
> This is surprising to me. What data are you basing this statement on [...]?
Nothing particularly concrete, but I've heard a bunch about wanting to forego "normal" CA certs for DANE-EE. Re browsers, I know of at least one extension that tries to verify DANE[1].
> getting the DNSSEC stuff done correctly with the all the keys etc to verify that the records we get are legitimate for the domain.
Yeah I'm personally proposing that curl shouldn't concern itself with this, asking the user to use a resolver that verifies DNSSEC is fairly reasonable to me.
In the case of the ad-hoc DoH resolver for ECH (and c-ares), it's probably best to "just" enable dnssec validation or fail the request entirely if not available/possible.
> Maybe you can start easy by explaining the libcurl API you have envisioned for this, and what actions that would trigger?
Sure, if we go the route of my proof-of-concept, the user would have to provide the TLSA/DANE records (wirefmt base64'd) via some CURLOPT[2]; a nicer extension could have libcurl do the resolution itself if requested, trusting the underlying resolver for DNSSEC validation.
Alternatively I can see an API that would take the records as parsed fields, but I think it's worth having more "generic" RR support - I know at least MX is/was being discussed at some point.
> It looks like you use c-ares for the DNS record fiddling, right?
Right, for ease of implementation really, though parsing that particular record type isn't _too much_ work in isolation.
[1]: <https://addons.mozilla.org/en-US/firefox/addon/dnssec-dane-padlock>
[2]: <https://github.com/alimpfard/ladybird/blob/d82765d82bbb823a0d56f75b9a13180bd5dd383c/Services/RequestServer/ConnectionFromClient.cpp#L446>
Am 1. September 2025 15:53:41 MESZ schrieb Daniel Stenberg <daniel_at_haxx.se>:
>On Mon, 1 Sep 2025, Ali Mohammad Pur Fard via curl-library wrote:
>
>Thanks for your interest and willingness to help improving curl!
>
>> Since DANE/TLSA has become much more common as a replacement for PKI
>
>This is surprising to me. What data are you basing this statement on and what PKI do you speak of here? The popular browsers don't support DANE, so deploying it for the web seems like a lot of work for a rather small audience.
>
>> In particular, I'm mostly interested in having libcurl expose a way for users to provide (or request the use of) a set of TLSA records, or somehow communicate that DANE should be used for the connection (as I'm trying to have DANE be a native alternative to PKI in Ladybird[1]). The request side of this is reasonably straightforward with openssl, at least.
>
>We added "Support DANE" to the TODO document already in August 2012. I think it would be cool to get support in and I know there is at least some interest "out there".
>
>We once had an attempt and I recall that we then had some challenges on getting the DNSSEC stuff done correctly with the all the keys etc to verify that the records we get are legitimate for the domain.
>
>> I do have a patchset[2] that implements this as a proof of concept
>
>Maybe you can start easy by explaining the libcurl API you have envisioned for this, and what actions that would trigger?
>
>It looks like you use c-ares for the DNS record fiddling, right?
>
>--
>
> / daniel.haxx.se || https://rock-solid.curl.dev
-- Cheers, ~Ali Mohammad Pur
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-09-01