Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 13 August 2018 20:43 UTC

Return-Path: <brian.peter.dickson@gmail.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 B4DC81310A9 for <dnsop@ietfa.amsl.com>; Mon, 13 Aug 2018 13:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8q5ukKs45Gn for <dnsop@ietfa.amsl.com>; Mon, 13 Aug 2018 13:43:12 -0700 (PDT)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922061310B7 for <dnsop@ietf.org>; Mon, 13 Aug 2018 13:43:12 -0700 (PDT)
Received: by mail-ua1-x92d.google.com with SMTP id o11-v6so10745102uak.5 for <dnsop@ietf.org>; Mon, 13 Aug 2018 13:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=n77k8gsjQDw+1GEmgQpQcM7EZBzrjgOulKOWFPncgGI=; b=kBGz97AfqlAJW3UDK0UqQuPdOHa/sHKRCPgieWYC0vqKA1i6pIm0TVMXGwFDH8v2vJ b27NRo6qtA1V/Jc2uvHJYdQqlnfOA5Exk6Ve7MTZ3w3iCToJH27Js9ENnE2SZrvisMJl jWJvfqxNIlEKPyW6jGJvR/vCdIprgfw3Jsmy+b/HH/e6vTGDub0y0E2A049lQR+znq83 jl8wUNJ4lK21jCg4eHS8oIlXnpXEyC9A+iRwLQw/vqR6MRjT5FsRJKsUumT2CZvOBBq2 Q2ksKa3sZ7FARPNlfeDs1ByqXNPW5pmjqvOt8gMHKDJd46ResepG+QDa6ISvnlABYTFt 5qAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n77k8gsjQDw+1GEmgQpQcM7EZBzrjgOulKOWFPncgGI=; b=Wrf9ZZ6XeIZsyT72MHqwhMVWlvFIy5cLIRHKicS6VYBrnFhEse5RhLqDjQlCfGpUPD LugktWDmEjQfGimH+Gwyb69TSpXCQl/Vt2//OsX3+lK5dAtpxfHp+jr27/mpDPMSvhhA hyrdo2QnM7eJqOniobFFi01DsBSiqiKdWcWfR0EqRTf6mWPKf53UlNAHcLzs0fPnoITo cnDcUboJl8p3s8TrES4KA89XK3DNWTN4zgEggf+I0w6gUJ0Lr/mw7awCKYaANq02WO3o T7OkLy3XmJCvS4wMVRMyNWf5TiltMvG+yd+a7KafRrw3RTcNbfEblRA2Yfw47i2F4oAQ J6sQ==
X-Gm-Message-State: AOUpUlGX7g2vBpKPBcbAGPHsgtrD7DMk8mqNT1hPWIKQNUypr//JJtbt wVAOpu0T4+nvFTWdMQuUlWFXKuto3jyT1lg85uX6VfS+
X-Google-Smtp-Source: AA+uWPxjE5WFCPFQM8+/y+Ztms9lHCy/AxaJwyAFKzloocAY+zcxXfLQntJZYu3SEeTQD8QxI9cXe/BZy4FSJBliBq0=
X-Received: by 2002:a9f:3f4b:: with SMTP id i11-v6mr2032618uaj.152.1534192991412; Mon, 13 Aug 2018 13:43:11 -0700 (PDT)
MIME-Version: 1.0
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 13 Aug 2018 13:42:54 -0700
Message-ID: <CAH1iCir=GH0oAkR-RBYqQbPLVvrO1nvx8js7bg7FqGAA7MPKbA@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004529c60573572495"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V2oS8nUHTzFzRd4-PpSFbGT0L3A>
Subject: Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2018 20:43:24 -0000

>
>
> Another limitation I've mentioned before, where DNSSEC doesn't protect you, is that a delegation could be falsified such that traffic goes to an eavesdropper that just records but doesn't modify messages.
>
> but on most networks you connect to that you don't trust, they could
> just be monitoring all your port 53 traffic anyway? I don't see this
> much as a use case. An attacker that cannot see your traffic, but could
> get to see your DNS root queries but only briefly if you cache or
> actually use the root zone you just transfered from them. Also query
> minimalization makes that use case very uninteresting.
>
>
While it is easy to misunderstand what Duane is referencing, or perhaps
there was some minimization on his part as well, there is a weakness caused
by the unsigned nature of delegations, whereby not protecting (e.g. via
zonemd) a publication point against a host of vulnerabilities, by
protecting the data itself, creates a very attractive target that lets an
adversary scale their attack very effectively.

Here's the gist of the problem, inherent in unsigned glue:
IF (big if, with the how/when/where etc kept as a separate discussion) an
attacker manages to modify glue (for example, poisoning a resolver's cache
for glue info), the attacker has the opportunity to selectively return
unmodified glue, or to replace further glue data (and continue to be a
DNS-MITM) and thus both view queries, and if/when the queries cross to
insecure delegations, modify non-glue data. For example, if there is a TLD
"foo", and the attacker manages to poison the A record for one (or more)
names of NS for "foo", the attacker can act as a forwarder for most *.foo
names, but then selectively modify the A records for the NS for "bar.foo",
and then for "blech.bar.foo", until there is an insecure delegation, at
which point the attacker can spoof any RR type for any name below that zone
cut. The attacker also has control over TTLs of any/all spoofed records,
modulo recursive resolver's TTL ceiling/floor. The attacker can gain
further information about the ongoing success of attacks by TTL-based
meta-monitoring (high TTL on delegation glue, low TTL on sub-delegation
glue, observe sub-delegation re-queries at the spoofed delegation point.)

Even in the case of an all-DNSSEC sub-tree, some attackers may see value in
observing ALL the queries (and answers);being a DNS-MITM (via modified
glue) achieves this, even for an off-path attacker who normally would not
have any visibility to the UDP/53 packets.

The above scenario works even on networks you trust, and even with
resolvers you know and trust, as long as there is the ability to attack the
glue. A single successful attack on a single resolver's glue has the
potential to result in a persistent long-lived DNS exploit, the scope of
which is largely limited by the attackers resources and/or intent and/or
desire to evade detection. Application of such an exploit is an exercise in
Kaminsky, i.e. the danger is obvious.

IMHO, this is the antithesis of "uninteresting".

The theoretical existence of this sort of attack, should be motivation
enough to advocate for greater DNSSEC deployment efforts. It should
motivate any and all methods of preventing undetected (and undetectable)
modification of glue records when copies of zone data are retrieved. A
centralized distribution point without data integrity protection of some
kind, becomes a very scalable place for an attacker to do bulk attacks
against large numbers of resolvers. A centralized distribution point WITH
data integrity protection that scales, provide protection against both
centralized AND decentralized (direct cache poisoning) attacks, thus
justifying the effort on doing this exact thing.

Brian Dickson

P.S. Documenting aspects of the more-than-theoretical poisoning attacks are
long overdue; when time permits, I will work on this, possibly with
interested parties. Any/all are welcome to work on this with me, FYI.