Re: I intend to have a document ready for Atlanta on this subject.

[Derek Atkins <derek@ihtfp.com>]

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.

> >Given the distributed nature of DNS, it is not at all clear that there
> >is a "large burden" problem.  Only zones which deign to serve key
> >records would suffer the burden of distributing them.
> >
> >And based on the discussion I've seen, I don't think "most observers"
> >hold the opinion you say that do.
>
> I'm not so sure ..but revisiting the discussion is useful .. the
> problem statement still exists and it is useful and productive work
> for the IETF to resolve.

Well, application keys certainly are "never" going to be stored or
delivered by the root servers or gtld servers.  The keys live out at
the leaves.  Assuming a key-in-DNS solution, by the time you're at the
leaf requesting a key, you've already passed though the high-load
servers to get the A record.  Getting the key is "easy", and only
requires a request to the leaf server.

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

-derek

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