[DNSOP] Re: Potentially interesting DNSSEC library CVE

Philip Homburg <pch-dnsop-5@u-1.phicoh.com> Thu, 25 July 2024 12:40 UTC

Return-Path: <pch-b538D2F77@u-1.phicoh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CBEC18DBA6 for <dnsop@ietfa.amsl.com>; Thu, 25 Jul 2024 05:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-EV_Iwi1JGa for <dnsop@ietfa.amsl.com>; Thu, 25 Jul 2024 05:40:16 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2BFC110D16 for <dnsop@ietf.org>; Thu, 25 Jul 2024 05:40:11 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1sWxlI-0000MGC; Thu, 25 Jul 2024 14:40:00 +0200
Message-Id: <m1sWxlI-0000MGC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-5@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
References: <m1sWF8d-0000LsC@stereo.hq.phicoh.net> <1070949df20a6ac1f9c2c2dd401d5953bb362bf2.camel@aisec.fraunhofer.de> <m1sWe2O-0000OKC@stereo.hq.phicoh.net> <fc306ade9816e06e19a1e2c9828c1c9ef2f0e2bb.camel@gnu.org> <m1sWxJi-0000MEC@stereo.hq.phicoh.net> <6c70aa6b316f7650d84a52135a6aa24aab147788.camel@gnu.org>
In-reply-to: Your message of "Thu, 25 Jul 2024 12:27:11 +0000 ." <6c70aa6b316f7650d84a52135a6aa24aab147788.camel@gnu.org>
Date: Thu, 25 Jul 2024 14:39:59 +0200
Message-ID-Hash: QYH2RROV4QV6G3YJVU24DLQSZWWCVS4T
X-Message-ID-Hash: QYH2RROV4QV6G3YJVU24DLQSZWWCVS4T
X-MailFrom: pch-b538D2F77@u-1.phicoh.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Martin Schanzenbach <schanzen@gnu.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Potentially interesting DNSSEC library CVE
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xMiofRlEL4shXRhVRowl__OEQOE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

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