[DNSOP] Re: Potentially interesting DNSSEC library CVE

[Martin Schanzenbach <[e-mail]>]

On Thu, 2024-07-25 at 14:39 +0200, Philip Homburg wrote:
> > 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?
> 
> By and large, the IETF defines network protocols. The IETF is not
> good
> a defining APIs for network functions. And it is not part of its core
> mission.
> 
> So what happens after a stub resolver receives a response is mostly
> undefined. Low level C APIs were done in the past by the IEEE (POSIX)
> and more
> recent by the Open Group.
> 
> For example RFC 3493 is not an IETF standard, but the functions
> described,
> such as getaddrinfo, are part of the Single Unix Specification.
> 
> > 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.
> 
> The gap is that there is no good standards organisation for APIs
> related to
> internet protocols. That is unfortunate. It is not clear to me who
> would
> have enough cloud to create one.

Are you trying to say that the behaviour of a validating stub resolver
is not in scope of the work on DNS(SEC)?
Because I was pretty sure it is.
See Thomas' post before on how separating validation from result
filtering (following the CNAME-chain) would be tricky to do outside of
the validating stub resolver (or only with significant overhead and re-
validation) for any implementation.

BR