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

[Shumon Huque <[e-mail]>]

2017-03-28 12:41 GMT-05:00 Paul Vixie <[e-mail]>:

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