[DNSOP] Re: Potentially interesting DNSSEC library CVE

[Martin Schanzenbach <[e-mail]>]

On Thu, 2024-07-25 at 14:11 +0200, Philip Homburg wrote:
> > I think this is the core issue behind the CVE and the filed bug.
> > Who is the "ultimate user"? And where is this expectation
> > formulated
> > exactly? I would believe that most applications using DNS libraries
> > such as dnsjava do not expect that they have to sift through CNAMEs
> > in the replies and filter according to their initial query.  So is
> > dnsjava in your opinion the "ultimate user" that is expected to
> > filter? If yes, "ultimate user" is an odd description because
> > dnsjava is a resolver implementation, whereas "ultimate user" to
> > me means application using a resolver (library/implementation).
> 
> The typical model is that of a library that implements a DNS stub
> resolver
> function. This library is expected to offer a function that takes a
> QNAME,
> QCLASS, and QTYPE as arguments and returns a set of resource records
> or an
> error.
> 
> If dnsjava implements the function of a stub resolver, then yes,
> dnsjava would
> be expected to sift through the CNAMEs. A stub resolvers speaks the
> DNS
> protocol and this is just how the protocol works.
> 
> 

As hinted to in the CVE description, Thomas asked here where this
behaviour is defined exactly and did not receive a response that fits
this issue:
https://mailarchive.ietf.org/arch/msg/dnsop/X7ul3Updo4XP0EYdExuZ6pkp-Gk/

Yes, of course a stub resolver will have to sift through the CNAMEs
(especially if DNSSEC validation is supposed to be done).
But where is the filtering between QNAME and received answers
explicitly defined, exactly?

> Obviously, you are free to define a new protocol that runs between a
> stub resolver and a recursive resolver. However, just compaining
> about the
> current situation is not going to change much.
> 

I am not complaining. I am pointing out that there is a root cause for
this CVE/bug and it may not be simple oversight. It very well may be a
gap in specification or missing security considerations that could hit
any future implementer of (stub) resolvers.

BR

> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]