Subject: RE: What I mumbled at the mike today...

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 12:10:38 -0700

> I think that you're still saying that zone enumeration is a
> security issue and not a privacy issue.  Am I correct?

Yes

> If you think that by not having a world-accessible DNS entry for a
> network-connected system you significantly improve its security
> posture, then I strongly disagree.  I've done penetration testing
> for many years and I also monitor IDS devices.  The simple facts
> today are that

How many Web Services devices have you managed?

> DNS data is only one of the inputs to the target selection
> process for network-based attacks and it's a minor one.  I
> don't expect that zone enumeration is going to suddenly
> change that, based on personal experience.

If your model of the Internet is limited to today's applications.

> I'm not saying that I want every outsider to have a perfect map
> of the internals of an enterprise network--but spending a lot of
> time preventing zone enumeration will also not keep bad guys from
> mapping networks or provide a useful improvement in security
> posture. 

the effort required to fix this issue is a trivial fraction of 
the effort trying to argue that it does not exist.

> Strongly disagree.  Declaring something as fact does not make
> it fact.

It is a fact that DNSSEC affects the visibility of data in the DNS
in ways that have significant security consequences.

The subjective issues are in the evaluation of those security 
consequences.

> > The DNS is nowhere near so pretty that it needs preservation as a 
> > national treasure. 
> 
> Agreed.  Simultaneously, the DNS is already ugly enough that
> continuing to add features and capabilities without considering
> all the impacts may be hazardous.

So why not do the job properly this time round instead of arguing
to do yet another half baked job?

>   --Rip (still looking for more inputs on the requirements
>     related to zone enumeration, NSEC, and DNSSEC in general, BTW)

Fix wildcards so that mid point wildcards work.

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

---

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 9 Aug 2004 15:44:33 -0400

Dr. Hallam-Baker--

> How many Web Services devices have you managed?
Apparently not enough to participate in a discussion
of DNS Security in an IETF context.  Funny, I didn't
see that on the "required qualification" list.

> If your model of the Internet is limited to today's applications.

My model of the future foundation of the Internet is unfortunately
limited to incremental improvements (to the existing foundation)
ideally while not screwing things up.  I'm still not clear
how XML-based "web services" are such a fundamental change to
the way Things Get Done that current security principles and
practices no longer apply.

> the effort trying to argue that it does not exist.

The effort required to fix this issue correctly once-and-for-all
is a non-trivial fraction of the available resources and may
cause further delays in widespread DNSSEC usage without producing
a significant benefity to many users.  With all due respect, I
believe you're still handwaving.  I share your impatience with
some IETF processes, but they are the constraints within which
we're working.

> The subjective issues are in the evaluation of those security 

It is a fact that DNSSECbis (through NSEC) affects the visibility
of data in the DNS in ways that have been well-known and well-
documented since RFC 2065 gave us the NXT RR in 1997.  I wasn't
happy about it then, but I decided I could live with it as
did many others--based on a realistic evaluation of the risks
involved.

The subjective issues are in the evaluation of the potential
consequences (security, privacy, or otherwise) of the effects,
resulting security risks (if any), and in the decision as to
what to do now.  I *still* don't understand why this discussion
got into security issues, and I need to understand things in
order that the requirements document is complete and comprehensible
(unless Ben can give me a Vulcan mind-meld or something, assuming
he does understand the issues to your satisfaction.)

> Fix wildcards so that mid point wildcards work.

Wow--I agree that mid-point wildcards would be very useful in
some contexts but I see them as very painful and/or a Bad Idea
in others.  I'm afraid that may also be beyond the immediate
scope of requirements that Ben and I were asked to compile,
but I do think it needs to be discussed at least once more--
and very soon since it needs to be taken into account as part
of the DNSSEC-what-now discussions.

Okay, who's doing wildcard requirements?

  --Rip

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 13:28:23 -0700

> see that on the "required qualification" list.

It would seem to be a useful qualification if you are going to 
argue the security requirements thereof.

> practices no longer apply.

Actually what I am saying here is that the security principles
considered in the Internet security field DO apply. What I reject
are the superstitious nonsense and pseudo-security doctrines that
pass for security arguments here.

> a significant benefity to many users. 

It will cause no delays whatsoever. You are so far from being 
deployed in the real world that it is just not funny. 

> in others. 

Wildcards ARE a really bad idea. But they are also used. And since
SRV appeared there are significant problems with the way they are
used.

Having been subjected to endless arguments about why wildcards make\
it impossible to use prefixes in the context of SPF I think we should
fix 'em.

I can draw up some requirements next week.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 13:35:59 -0700

> You are thus presumably not concerned (here) about wire-tap /
> man-in-the-middle type attacks where queries (and answers) 
> get recorded
> by third parties - IE it is not a requirement in your book to (for
> instance) encrypt the query and/or response?

Actually I do have real concerns here, but confidentiality is not
something that can be addressed in an end to end protocol in the
context of DNS while authenticity is.

Encrypting DNS is something like issue number 37 on my list of
urgent fixes to Internet security protocols. It will not be 
relevant until a whole host of other stuff is fixed first and 
there will be no viable way to address it until there is 
DNS authentication security.

Basically my approach would be to perform point to point 
encryption using session keys generated through an ephemeral 
key exchange.