Re: Using/validating DANE certs?

Timothe Litt via curl-library <[email protected]> Thu, 11 Sep 2025 06:24:31 -0400
Newsgroups	gmane.comp.web.curl.library
Message-ID	<[email protected]>
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
OpenPGP_signature.asc (application/pgp-signature, 495 B)