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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
