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: Mon, 8 Sep 2025 15:58:29 +0200 (CEST)
On Sun, 7 Sep 2025, Ali Mohammad Pur wrote:
> we can trust the resolver, or do our own DNSSEC validation locally - no
> other possible way.
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.
> If a user doesn't trust their resolver, maybe they should not be using it? I
> do understand that my suggestion expands the trust base, however.
That's why TLS and the CA system is built *on-top* of it. If the DNS brings
back the wrong info, the certficate check fails and we get no data. We don't
need to trust the resolver for this.
I claim that most users (in the most large-scale sense possible of users)
don't run a DNSSEC secured local resolver so untrusted DNS data is the
default.
> That's reasonable, I'd be in favour of verifying DNSSEC locally for all
> cases even (sadly not very viable though, a big chunk of the open web would
> fail 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.
Date: Mon, 8 Sep 2025 15:58:29 +0200 (CEST)
On Sun, 7 Sep 2025, Ali Mohammad Pur wrote:
> we can trust the resolver, or do our own DNSSEC validation locally - no
> other possible way.
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.
> If a user doesn't trust their resolver, maybe they should not be using it? I
> do understand that my suggestion expands the trust base, however.
That's why TLS and the CA system is built *on-top* of it. If the DNS brings
back the wrong info, the certficate check fails and we get no data. We don't
need to trust the resolver for this.
I claim that most users (in the most large-scale sense possible of users)
don't run a DNSSEC secured local resolver so untrusted DNS data is the
default.
> That's reasonable, I'd be in favour of verifying DNSSEC locally for all
> cases even (sadly not very viable though, a big chunk of the open web would
> fail 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.
-- / 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-08