[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Derek Atkins <derek@ihtfp.com>
Cc: Greg Hudson <ghudson@MIT.EDU>, keydist@cafax.se, smb@research.att.com, jis@MIT.EDU
From: Richard Shockey <rich.shockey@NeuStar.com>
Date: Fri, 04 Oct 2002 12:40:46 -0400
In-Reply-To: <sjmu1k2yjwz.fsf@kikki.mit.edu>
Sender: owner-keydist@cafax.se
Subject: Re: I intend to have a document ready for Atlanta on this subject.

At 11:14 PM 10/3/2002 -0400, Derek Atkins wrote:
>Richard Shockey <rshockey@ix.netcom.com> writes:
>
> > I accept and support the notion that the line has been drawn in the
> > DNS with application specific PKI and its time to solve the problem
> > associated with it.
>
>Except no such line has been drawn.  Some people would like to draw
>it, but there is certainly no concensus that such a line exists.
>There are certainly cases for which storing application keys directly
>in the DNS is absolutely the right solution.  On the other hand,
>nothing says that it has to be the only solution.

agreed.... so long as you agree that the argument for pointers is just as
valid as that for direct storage.



> > Again I still submit that pointers are more useful more flexible and
> > that the burden is therefore distributed and not placed on the DNS
> > servers which has enough to do as it is. Again I support the ongoing
> > admonitions about further burdening the DNS. I belive that a strict
> > separation between infrastructure uses of PKI and applications is
> > necessary and required.
>
>I would argue that pointers add unnecessary indirection and extra
>round trips.  Indirection is not always a good thing.  In fact, when
>security is concerned, the fewer indirections the better: fewer things
>for the protocol designer or implementor to get wrong or forget to
>check.

Now we clearly part ways ... I do not see extra round trips as a problem
..we have lots of applications that use them its done all the time. ENUM,
SIP etc are clearly two that use NAPTR records. You may not like DDDS but
it is more flexible and definable. Clearly state the input stream and the
well known rules and it can be easily coded.

Your security point is well taken however fewer indirections are a "good
thing" but I will trade that for a more diverse and distributed
infrastructure.


>-derek
>
>--
>        Derek Atkins
>        Computer and Internet Security Consultant
>        derek@ihtfp.com             www.ihtfp.com


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:richard@shockey.us> or <mailto:richard.shockey@neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Home | Date list | Subject list