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: Timothe Litt <litt_at_acm.org>
Date: Thu, 11 Sep 2025 06:24:31 -0400
On 11-Sep-25 04:47, Daniel Stenberg wrote:
> On Mon, 8 Sep 2025, Timothe Litt via curl-library wrote:
>
>> Implementing DNSSEC validation in an application is discouraged in 3655.
>>
>> It's analogous to implementing TCP over UDP in the application
>> because you don't trust the kernel's TCP stack...
>
> I beg to differ. That's a completely different matter.
>
> 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.
Even if curl were to (correctly) validate responses itself, it would
ultimately count on the root zone's signing keys. You start with those
built-in - obtained from the WWW. Somehow, you convince yourself that
you got the right ones - that you weren't talking to a malicious
resolver that sent you to a fake set of keys. And a fake set of root
servers. If you follow the RFCs, that means consulting multiple sources
and ensuring consistency. While difficult, a state actor could probably
fake that. Then, you have to handle key rollover; for a recent
overview, see
https://blog.verisign.com/security/2024-2026-root-zone-ksk-rollover-initial-observations/.
Is curl going to distribute the root signing keys? Implement RFC5011
for roll-over? Implement the full DNSSEC validation - including the
NSEC* denial of existence, ever-changing signature algorithms allowed
(and disallowed), multiple published keys, and expiration/validity
timers? That a big project, and serious scope expansion for curl.
Absent persistent (and trustworthy) caching, the connect times would
also be a concern. (Each invocation of the tool would have to start
validating from scratch.)
DANE itself (mode 0 &1 - CA, CA-issued cert) requires that the
application user *trust *an X.509 root certificate list. Usage 2 & 3
(private trust anchor & self-signed) short-circuit the X.509 root; the
TLSA record is the only source of truth.
Any application user has to decide when to extend trust. If (s)he
relies on someone else to pick the DNS servers (as most do), the
application is vulnerable to bad choices. If (s)he runs the DNS
server(s), the application is vulnerable to misconfiguration (and code
bugs). Either way, if the user (or someone (s)he trusts) configures a
DNS resolver that lies about DNSSEC resolution, all applications are at
risk. The way to protect against those threats is to use secure
communication to a vetted resolver. The same applies to the choice and
transport of a X.509 root certificate list.
This applies to your web browser, your mail server, your NTP server
(among others) - and curl. RFC3655
<https://datatracker.ietf.org/doc/html/rfc3655> (merged into later RFCs,
but not changed) includes:
> The AD bit SHOULD be used by the local resolver if and only if it has
> been*explicitly configured to trust* the remote resolver. The AD bit
> SHOULD be ignored when the recursive name server is not trusted.
>
> An alternate solution would be to embed a full DNSSEC resolver into
> every application, but this has several disadvantages.
>
> -*DNSSEC validation is both CPU and network intensive, and caching
> SHOULD be used whenever possible.*
>
> -*DNSSEC requires non-trivial configuration - the root key must be
> configured, as well as keys for any "islands of security" that will
> exist until DNSSEC is fully deployed.* The number of
> configuration points should be minimized
It further makes clear that t*rust is a user (and not an application)
responsibility*:
> The AD bit MUST only be
> trusted when*the end consumer of the DNS data has confidence that the intermediary
> resolver setting the AD bit is trustworthy.* This can
> only be accomplished via an out of band mechanism such as:
>
> - Fiat: An organization that can dictate whether it is OK to trust
> certain DNS servers.
>
> - Personal: Because of a personal relationship or the reputation of
> a recursive nameserver operator, a DNS consumer can decide to
> trust that recursive nameserver.
>
> - Knowledge: If a recursive nameserver operator posts the configured
> policy of a recursive nameserver, a consumer can decide that
> recursive nameserver is trustworthy.
>
> In the absence of one or more of these factors AD bit from a
> recursive name server SHOULD NOT be trusted. For example, home users
> frequently depend on their ISP to provide recursive DNS service; it
> is not advisable to trust these recursive nameservers. A
> roaming/traveling host SHOULD not use recursive DNS servers offered
> by DHCP when looking up information where security status matters.
> In the latter two cases,*the end consumer must also completely trust the path to the
> trusted recursive name servers, or a secure transport must be
> employed to protect the traffic. *
> *When faced with a situation where there are no satisfactory recursive
> nameservers available, running one locally is RECOMMENDED*. This has
> the advantage that it can be trusted, and the AD bit can still be
> used to allow applications to use stub resolvers.
And
> Resolvers (full or stub) that blindly trust the AD bit without
> knowing the security policy of the server generating the answer can
> not be considered security aware.
>
> *A resolver MUST NOT blindly trust the AD bit unless it communicates
> such as IPsec, or using message authentication* such as TSIG [RFC2845 <https://datatracker.ietf.org/doc/html/rfc2845>]
> or SIG(0) [RFC2931 <https://datatracker.ietf.org/doc/html/rfc2931>]. In addition,*the resolver must have been explicitly configured to trust* this recursive name server.
DANE won't protect against all threats. What it CAN do is limit the
exposure to rogue X.509 CAs by specifying the trust anchor or
certificate to be used. To do that, it relies on DNSSEC. DNSSEC is
exposed to applications by resolvers.
In a perfect world, DANE would not be implemented in curl (or any
application); it should be a system library tightly integrated with the
system's local/stub resolver. E.g. with an API of (connect to this host
on this protocol/port, validating by all available means).
It's not a perfect world. But curl shouldn't take on replicating the
functions of other available services. Nor can it protect against
malicious (untrustworthy, or careless) system administrators.
See "systemd" for the challenges and reputational damage that can result...
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2025-09-11
Date: Thu, 11 Sep 2025 06:24:31 -0400
On 11-Sep-25 04:47, Daniel Stenberg wrote:
> On Mon, 8 Sep 2025, Timothe Litt via curl-library wrote:
>
>> Implementing DNSSEC validation in an application is discouraged in 3655.
>>
>> It's analogous to implementing TCP over UDP in the application
>> because you don't trust the kernel's TCP stack...
>
> I beg to differ. That's a completely different matter.
>
> 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.
Even if curl were to (correctly) validate responses itself, it would
ultimately count on the root zone's signing keys. You start with those
built-in - obtained from the WWW. Somehow, you convince yourself that
you got the right ones - that you weren't talking to a malicious
resolver that sent you to a fake set of keys. And a fake set of root
servers. If you follow the RFCs, that means consulting multiple sources
and ensuring consistency. While difficult, a state actor could probably
fake that. Then, you have to handle key rollover; for a recent
overview, see
https://blog.verisign.com/security/2024-2026-root-zone-ksk-rollover-initial-observations/.
Is curl going to distribute the root signing keys? Implement RFC5011
for roll-over? Implement the full DNSSEC validation - including the
NSEC* denial of existence, ever-changing signature algorithms allowed
(and disallowed), multiple published keys, and expiration/validity
timers? That a big project, and serious scope expansion for curl.
Absent persistent (and trustworthy) caching, the connect times would
also be a concern. (Each invocation of the tool would have to start
validating from scratch.)
DANE itself (mode 0 &1 - CA, CA-issued cert) requires that the
application user *trust *an X.509 root certificate list. Usage 2 & 3
(private trust anchor & self-signed) short-circuit the X.509 root; the
TLSA record is the only source of truth.
Any application user has to decide when to extend trust. If (s)he
relies on someone else to pick the DNS servers (as most do), the
application is vulnerable to bad choices. If (s)he runs the DNS
server(s), the application is vulnerable to misconfiguration (and code
bugs). Either way, if the user (or someone (s)he trusts) configures a
DNS resolver that lies about DNSSEC resolution, all applications are at
risk. The way to protect against those threats is to use secure
communication to a vetted resolver. The same applies to the choice and
transport of a X.509 root certificate list.
This applies to your web browser, your mail server, your NTP server
(among others) - and curl. RFC3655
<https://datatracker.ietf.org/doc/html/rfc3655> (merged into later RFCs,
but not changed) includes:
> The AD bit SHOULD be used by the local resolver if and only if it has
> been*explicitly configured to trust* the remote resolver. The AD bit
> SHOULD be ignored when the recursive name server is not trusted.
>
> An alternate solution would be to embed a full DNSSEC resolver into
> every application, but this has several disadvantages.
>
> -*DNSSEC validation is both CPU and network intensive, and caching
> SHOULD be used whenever possible.*
>
> -*DNSSEC requires non-trivial configuration - the root key must be
> configured, as well as keys for any "islands of security" that will
> exist until DNSSEC is fully deployed.* The number of
> configuration points should be minimized
It further makes clear that t*rust is a user (and not an application)
responsibility*:
> The AD bit MUST only be
> trusted when*the end consumer of the DNS data has confidence that the intermediary
> resolver setting the AD bit is trustworthy.* This can
> only be accomplished via an out of band mechanism such as:
>
> - Fiat: An organization that can dictate whether it is OK to trust
> certain DNS servers.
>
> - Personal: Because of a personal relationship or the reputation of
> a recursive nameserver operator, a DNS consumer can decide to
> trust that recursive nameserver.
>
> - Knowledge: If a recursive nameserver operator posts the configured
> policy of a recursive nameserver, a consumer can decide that
> recursive nameserver is trustworthy.
>
> In the absence of one or more of these factors AD bit from a
> recursive name server SHOULD NOT be trusted. For example, home users
> frequently depend on their ISP to provide recursive DNS service; it
> is not advisable to trust these recursive nameservers. A
> roaming/traveling host SHOULD not use recursive DNS servers offered
> by DHCP when looking up information where security status matters.
> In the latter two cases,*the end consumer must also completely trust the path to the
> trusted recursive name servers, or a secure transport must be
> employed to protect the traffic. *
> *When faced with a situation where there are no satisfactory recursive
> nameservers available, running one locally is RECOMMENDED*. This has
> the advantage that it can be trusted, and the AD bit can still be
> used to allow applications to use stub resolvers.
And
> Resolvers (full or stub) that blindly trust the AD bit without
> knowing the security policy of the server generating the answer can
> not be considered security aware.
>
> *A resolver MUST NOT blindly trust the AD bit unless it communicates
> such as IPsec, or using message authentication* such as TSIG [RFC2845 <https://datatracker.ietf.org/doc/html/rfc2845>]
> or SIG(0) [RFC2931 <https://datatracker.ietf.org/doc/html/rfc2931>]. In addition,*the resolver must have been explicitly configured to trust* this recursive name server.
DANE won't protect against all threats. What it CAN do is limit the
exposure to rogue X.509 CAs by specifying the trust anchor or
certificate to be used. To do that, it relies on DNSSEC. DNSSEC is
exposed to applications by resolvers.
In a perfect world, DANE would not be implemented in curl (or any
application); it should be a system library tightly integrated with the
system's local/stub resolver. E.g. with an API of (connect to this host
on this protocol/port, validating by all available means).
It's not a perfect world. But curl shouldn't take on replicating the
functions of other available services. Nor can it protect against
malicious (untrustworthy, or careless) system administrators.
See "systemd" for the challenges and reputational damage that can result...
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature