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

Paul Vixie <paul@redbarn.org> Wed, 29 March 2017 18:33 UTC

Return-Path: <paul@redbarn.org>
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 29C3512025C for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 11:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jEiYduXa0PXp for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 11:32:53 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA5C127863 for <dnsop@ietf.org>; Wed, 29 Mar 2017 11:32:53 -0700 (PDT)
Received: from [10.199.15.136] (unknown [12.219.129.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 3455261F9C for <dnsop@ietf.org>; Wed, 29 Mar 2017 18:32:52 +0000 (UTC)
Message-ID: <58DBFDD3.7010507@redbarn.org>
Date: Wed, 29 Mar 2017 11:32:51 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.12 (Windows/20170323)
MIME-Version: 1.0
To: "dnsop@ietf.org" <dnsop@ietf.org>
References: <58DAA053.5030702@redbarn.org> <CAHPuVdWGHqDcA2VPrrrHbKi38i17PogAkBT71Eg6RS7T3RcejQ@mail.gmail.com>
In-Reply-To: <CAHPuVdWGHqDcA2VPrrrHbKi38i17PogAkBT71Eg6RS7T3RcejQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/liIKtyGWbZQl0D6Julp2fxezZIs>
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 18:33:01 -0000


Shumon Huque wrote:
> 2017-03-28 12:41 GMT-05:00 Paul Vixie <paul@redbarn.org:
> 
>     ...
> 
>     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').
> 
> ...
> 
> These systems see a lot, no doubt, but they are still limited to data
> contributed by the set of participating resolvers. ...

DNSDB coverage gets better every year. other passive systems report the
same. systems of this kind are vital for both operational security and
security research, and are part of a very strong and virtuous cycle.

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

for the purpose of this thread, that doesn't matter. anyone who wants to
enumerate dns content can do so, well enough, given access to one or
more passive dns systems, which is more available and also easier than
enumeration, especially because it does not rely on active queries, so
the zone administrator can't detect it.

under nsec5, something that's already harder to do than passive dns,
will get harder. this is an irrelevant benefit, with a very relevant cost.

the only practical benefit of nsec3 is opt-out, and this was true even
before the pre-image enumeration vulnerability was "discovered". nsec3's
anti-enumeration capability was merely a necessary "fig leaf" for some
cctld operators whose national privacy laws prohibited NSEC-walking.

> The fact that systems like this exist, does not invalidate the desire
> for the DNS protocol to prevent easy "bulk disclosure" of zone content.

yes, it does.

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

had we completed the work after nine years, so, ten years ago, and had
there been no new flag days since then, i think it would be generally
implemented by recursives (validation), authorities (signatures),
registries and registrars. and there might be an app or two, such as
DANE, in general use.

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

i can post more exerpts from the dns-security mailing list from 1996, or
from dnsind in 2005, if i've failed to convince you. there is no
generally perceived benefit from dnssec deployment today, but that is an
effect of the nineteen (19) years we have now been "working on it".

if there's no market for dnssec itself, then for that reason and to
exactly the same extent, there is no market for nsec5. if anyone would
like a demo of passive dns, please send me some nameservers, or ip
address blocks, or domain names. because, if you put something in the
dns, and somebody looks it up (ever), then it is public information. we
have got to stop arguing that it can be simultaneously kept secret.

-- 
P Vixie