Re: Using/validating DANE certs?

[Timothe Litt via curl-library]

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.




       configuration points should be minimized

-*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

It further makes clear that t*rust is a user (and not an application) responsibility*:

The AD bit MUST only be

    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.

    the advantage that it can be trusted, and the AD bit can still be
    used to allow applications to use stub resolvers.

trusted when*the end consumer of the DNS data has confidence that the intermediary resolver setting the AD bit is trustworthy.* This can    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

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.

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.

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.

OpenPGP_signature.asc
Description: OpenPGP digital signature

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html