Re: [DNSOP] on zone enumeration and the futility of secrecy on authenticated denial

Shumon Huque <shuque@gmail.com> Wed, 29 March 2017 17:32 UTC

Return-Path: <shuque@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 A6729129453 for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 10:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 3N7al_-UXxKA for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 10:32:08 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 9F3801272E1 for <dnsop@ietf.org>; Wed, 29 Mar 2017 10:32:06 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id s68so26312799vke.3 for <dnsop@ietf.org>; Wed, 29 Mar 2017 10:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gi7YdWqSrx5+Hbva9HT47Qmzs0pmb9r9RQNfdKZDq6M=; b=NFSD4ukOz1g2O/4duxtNq9zVdBZtMoBuvNsUYWnYwvaEYDKb4TyRW/UGp29xtDERPU DCYFDkczlQdhkWHz7+FuZ0jCzK1X5SWtF43JdouBtoltWXi9GGA+rstpu9xNFSOoNT3B LCGsWofQe8cQI3Y+1PtjKclhKTJQtCrvtuJvZpa1UJtq0YtmPXof11hJFRhrWpq8ZyGr iXNdnSsB1s2kvbnSkyKvIcuV1fkdkfm1UqLRmvZR6Ca1m18+71PLd0c7NMPTfkc18mAH qvLm/aF/a50xRad8MGyEyADT8KGGauQ2w2XkMWKzyBDy4CG4ULrRkv8U2xAQbZQv9JzO x+8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gi7YdWqSrx5+Hbva9HT47Qmzs0pmb9r9RQNfdKZDq6M=; b=Yp5uy2fco9e4en0ivDtUu/HU6wQw8guBU7aEouO9s5/J45nRqzvMx2s5FdSJ8hASK7 Mfy7+9OXZqvUOOh2cI3HI7YVc4bFnO8tzLL9A2ANDTxD01eu/058Od4aTPHFK9GBbXdV G8sypeS126JGfZuWgDMhna6NtaqmdHJ3V71hSnmqH4NVLFIydeJT9p2Gy2lS711mp5WN qYjXpF/yigDhsBU02oFKxbqrVJeyKIzVzJPGKRMbYY1sYqpYtkWIlyCF3GN7+cMQ9GYq OlKSUH76pjV82Cpc1Q5pjiGEBlzGXY5qJqML3QnQk7/oIo6jMpIVhdBMP57W3Lf367nO qI+g==
X-Gm-Message-State: AFeK/H1LPMPo34claN5BuwZ4juPZlE4RxtjCYGRfpM8qe6utX+FZI7Mb6fMxy4O5KeoliM2YrgYxXj3mujxKpA==
X-Received: by 10.31.63.2 with SMTP id m2mr739770vka.6.1490808725656; Wed, 29 Mar 2017 10:32:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.84.207 with HTTP; Wed, 29 Mar 2017 10:32:05 -0700 (PDT)
In-Reply-To: <58DAA053.5030702@redbarn.org>
References: <58DAA053.5030702@redbarn.org>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 29 Mar 2017 12:32:05 -0500
Message-ID: <CAHPuVdWGHqDcA2VPrrrHbKi38i17PogAkBT71Eg6RS7T3RcejQ@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=001a114dafea855ead054be1f405
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3aE9K5E_dzPkr72Wv8RJxIyO2Xg>
Subject: Re: [DNSOP] on zone enumeration and the futility of secrecy on authenticated denial
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 29 Mar 2017 17:32:11 -0000

2017-03-28 12:41 GMT-05:00 Paul Vixie <paul@redbarn.org>rg>:

> at DNSOP yesterday i asked that anyone who thought zone enumeration was
> a risk and that any crypto change (such as NSEC5) could manage that risk
> should please accept a free demonstration of passive dns.
>
> i realized that i could offer this more broadly. here is *.vix.su, one
> of my vanity domains. passive dns works by storing cache miss traffic
> (so there is no PII here). DNSDB, whose result is shown below, is one of
> about a dozen security-community projects who aggregate these cache
> misses into searchable databases.
>
> summary: all dns content is running naked through the forest covered in
> honey. if you put something into the dns, and it gets used, then it's
> going to be known. no amount of crypto on dnssec authenticated denial is
> going to change that. (nor will the DPRIVE effort, since passive dns
> relies on inside-the-RDNS-servers cooperation, such as for example
> 'dnstap').
>

Hi Paul,

I'm quite familiar with DNSDB and similar passive DNS systems and would
guess that many in the DNSOP crowd are also. Some years ago, when I
worked in the US R&E  community, I used DNSDB to enumerate most of the
.edu TLD to do DNSSEC deployment statistics and analyses.

These systems see a lot, no doubt, but they are still limited to data
contributed by the set of participating resolvers. And as far as I know,
they aren't open to inspection by the world (usually only participating
resolvers, researchers, and customers of the passive DNS service).

The fact that systems like this exist, does not invalidate the desire
for the DNS protocol to prevent easy "bulk disclosure" of zone content.
The DNS privacy considerations RFC for example has a section that
provides such arguments - the protocol queries public data, but you have
to know what to query for, and mechanisms that permit mass leakage of
such data are undesirable. Similarly, the fact that website observatories
exist doesn't mean that the web protocol should provide a mechanism to
enumerate all website names hosted at a CDN for example.

Before DNSSEC, enumerating zone content was only possible by means
of online queries of candidate names. NSEC and NSEC3 made that problem
strictly worse (walking the NSEC chain, and offline dictionary attack
of the NSEC3 chain). NSEC5 restores the pre-DNSSEC property that only
online guessing works.

Perhaps passive dns will become so prevalent, all-encompassing, and
accessible that it isn't worth investing time in doing better than NSEC3,
but let's have that discussion as a community.


> nsec5 is a work of beauty and wonder. but changing the DNSSEC protocol
> every two years is why we're 19 years in and still lack ubiquitous
> deployment. adding more complexity would have to pay back more cost than
> any new form of authenticated denial could even theoretically do.
>

I don't think protocol evolution can be blamed for lack of ubiquitous
DNSSEC deployment. In my experience, most people who haven't
deployed it, don't see any immediate compelling need for it. If cache
poisoning and DNS MITM attacks were happening on a large scale
(they aren't), that would act as a deployment incentive. If there were
a killer app that depended on DNSSEC (perhaps DANE will be that
some day down the road), that would also be an incentive.

Another deployment disincentive is that DNSSEC has a generally
bad rap in the larger technical community. Much of it is based on
FUD and misunderstanding. But there are legitimate criticisms that we
ought to be paying more attention to - DNSSEC deployment is littered
with 1024-bit RSA is one. Zone enumeration obviously is another.

Shumon.