Subject: NSEC++ and protecting zone metrics (was: NSEC3 chain walking)

From: "Loomis, Rip" <[email-masked]>
Date: Tue, 1 Nov 2005 13:37:28 -0500

Mostly a <me too> for what Ben just said, but a few additional
thoughts, and a poor attempt at a modified subject line in the
hopes that anyone who cares might actually read it:

<hat color="requirements I-D co-editor">

> >> We decided in 
> >> [[draft-ietf-dnsext-signed-nonexistence-requirements-02.txt]]
> >> that it was "nice to have" and not an actual requirement.
> > 
> > not to question your assessment in this case, but the message
> > should probably be that "we" (be that the editors or the WG) 
> > should be careful about other people's requirements, especially
> > if they are crucial for a deployment success.
> 
> This was on the basis that no-one said it was their requirement.

More specifically:  This was postulated as an attribute that
"someone might want" but no one from the WG or the larger
community did in fact state any need for this attribute.
Between Ben and I, and several other folks who we asked, no
one was able to even come up with a situation where this attribute
was at all of concern.

My professional opinion:  An organization which is so paranoid
about its DNS information that it considers the number/type of RRs
in a zone file to be sensitive needs to move that zone off the
Internet and protect it appropriately--one simply cannot expect
to have a registry of public information that provides these additional
security features (DNSSEC extensions) while simultaneously
protecting such seemingly innocuous information.  Even having used
DNS information as part of security evaluations and "penetration
testing" I still can't postulate a way that this particular
information could be usefully (or even non-usefully) abused.

That being said:  If someone really needs this attribute or
considers it a highly desirable feature, then they need to
make the case and it would go from 'desirement' to 'requirement'.
I have no problem editing the draft based on actual input, but
I have little interest in making all possible attributes
equally desirable/needed.

> > It might be quite easy to get feedback from TLD registries, 
> > but there are other DNS operators who may not have made
> > their mind and, if they do, might disagree with the above
> > categorization (as "nice to have").
> 
> True. However, given that we have established the impossibility of
> satisfying all plausible requirements we are obliged to choose amongst
> them, are we not?
> 
> I'd also note that it is not generally required of WGs that 
> they should attempt to achieve consensus with non-participants!

What he said.  More specifically, having some background in
both security and system administration I've really tried
hard to think about the types of information that warrant
protection--and other folks smarter than I am have done the
same.  The fact is that this remains a "postulated useful
attribute" that no one has actually requested.

> > When it comes to "zone size" and "zone enumeration", it's 
> > also important to view the first order differential, i.e.
> > dies NSEC++ make it easier (than pre-DNSSEC DNS) to find
> > the [number of] changes applied to zone?
> > (This is not to introduce new hurdles, just completeness of 
> > the requirements list).
> 
> Surely the appropriate differential is against NSEC in this 
> case, since NSEC3 is not designed to solve this particular
> problem, so the requirement is surely to not make it worse
> than NSEC, if possible, and if anyone cares at all.

For my part, I considered the way NXT created a linked list
to be "bad" back in 1999 when I first stuck my nose into
it--so I want to actually do things sufficiently correctly
this time baselined against plain-old-DNS-today.  I also
want this to be the last flag day that is even contemplated
for quite a while, which implies fixing things both *soon*
and *well*.

But again, although metrics such as zone size, zone RRtype
composition, and zone entry thrash/change percentage are all
possibly of interest to someone (for some perceived competitive
advantage even if not from a security perspective), no entity
to date has stated a need much less a clear basis for that
need.

Comments requested, preferably clear statements of need (with
basis) or clear statements that this sort of thing is *not*
an issue for $organization.  I don't disagree with Peter K.
for raising the issue again, since we need quickly to agree
on the basis for reviewing any proposed NSEC++ methods.

</hat>

Rip Loomis, CISSP, PMP
=-=-=-=-=-=
Senior Systems Security Engineer    http://www.saic.com/infosec/
SAIC - Integrated Security and Systems Solutions  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>