> 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 <[email protected]>:
>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.html
