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: Tue, 2 Sep 2025 18:02:07 +0200 (CEST)
On Mon, 1 Sep 2025, Ali Mohammad Pur wrote:
> 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].
Are there actual web sites on the internet deployed with CA certs in DNS
beyond just singular experiments?
DANE seems mostly implemented for SMTP where I'm looking.
>> 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.
Won't that immediately discard a rather sizable portion of users? I would
guess that a majority of users don't run one on the machine they invoke curl
on. How would curl figure out that it works with a resolver that verifies
DNSSEC?
> 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];
How is that different from just providing a CACERT bundle in a dedicated file?
> a nicer extension could have libcurl do the resolution itself if requested,
> trusting the underlying resolver for DNSSEC validation.
I don't think we should build functionality on the plain assumption that users
will use trusted resolvers with working DNSSEC validation. Especially as I
suspect that's a minority of users.
It also makes it a rather flaky functionality that will break or not break
fairly arbitrarily in the eyes of the user, depending on how the local
resolver works or doesn't work.
> 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.
I don't understand how "generic RR support" helps curl users work with DANE,
and I don't think MX is a record curl needs to care about.
Date: Tue, 2 Sep 2025 18:02:07 +0200 (CEST)
On Mon, 1 Sep 2025, Ali Mohammad Pur wrote:
> 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].
Are there actual web sites on the internet deployed with CA certs in DNS
beyond just singular experiments?
DANE seems mostly implemented for SMTP where I'm looking.
>> 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.
Won't that immediately discard a rather sizable portion of users? I would
guess that a majority of users don't run one on the machine they invoke curl
on. How would curl figure out that it works with a resolver that verifies
DNSSEC?
> 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];
How is that different from just providing a CACERT bundle in a dedicated file?
> a nicer extension could have libcurl do the resolution itself if requested,
> trusting the underlying resolver for DNSSEC validation.
I don't think we should build functionality on the plain assumption that users
will use trusted resolvers with working DNSSEC validation. Especially as I
suspect that's a minority of users.
It also makes it a rather flaky functionality that will break or not break
fairly arbitrarily in the eyes of the user, depending on how the local
resolver works or doesn't work.
> 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.
I don't understand how "generic RR support" helps curl users work with DANE,
and I don't think MX is a record curl needs to care about.
-- / 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-02