From: "Kipp E.B. Hickman" <kipp@warp.mcom.com>
Date: Mon, 12 Dec 94 16:02:12 PST
To: perry@imsi.com
Subject: Re: Clarification of my remarks about Netscape
In-Reply-To: <9412122322.AA11307@snark.imsi.com>
Message-ID: <9412121600.ZM17661@warp.mcom.com>
MIME-Version: 1.0
Content-Type: text/plain


On Dec 12,  6:22pm, Perry E. Metzger wrote:
> Subject: Re: Clarification of my remarks about Netscape
>
> "Kipp E.B. Hickman" says:
> > Clearly you and I disagree on a fundamental point. Which is more
> > important?  Securing the document or securing the transport of the
> > document. I believe that today's problem for commerce is securing
> > the transport.
>
> I believe there is a fundamental problem of understanding here -- it
> does not seem that you understand how store and forward email
> works. Securing just the transport is less than useless.

SSL does not provide solutions for the class of problems elucidated by
store-and-forward mail systems. However, it does promise that the transmission
between two mail agents will be private. Depending on the configuration of your
network this may be all you need. Using SSL to "privatize" SMTP transmissions
seems useful to me. If the data being transmitted were PEM then all the better.

> > Solving this currently widespread problem makes the
> > Internet a friendlier place for commerce. It allows sensitive
> > information to be transported privately.
>
> No, it does not -- it just means that some links can't be read. On the
> other hand, PEM/MIME-PEM *ALREADY* keep people from reading no matter
> whether the link is open or not open.
>
> > Let's pretend for a moment that you are right. IPSP is the way to
> > go, today, and that silly us, we should have used it. So now I go to
> > my site manager, and say:
> >
> > 	Please replace all that fancy expensive network hardware with new
> > 	ones that speak IPSP so that we can do private communications with...
>
> You don't have to replace any hardware. More ignorance on your part.

Something somewhere has to be able to speak IPSP. Something must be changed,
even if it's just software. If it is just software, then I have an upgrade
problem because in our network we have one machine from every workstation
manufaturer and every kind of PC and MAC imaginable. This is not uncommon, and
is a logistics nightmare. Once a service is relegated to only allowing private
communications, you are just as stuck as we are. There will be a class of
hardware/software that cannot communicate.

This upgrade problem exists no matter what security technology is used.

>
> > So who can I talk to? Name one router that speaks the secure
> > protocols you are documenting?
>
> Each and every one routes it today. I have routed swIPe packets
> over the commercial internet -- and of course I couldn't control any
> of the intervening routers. Your comments indicate that you are
> totally unaware of how IPSP is designed to work.
>
> You are ignorant and foolish. You could at least read a document or
> two before making statements that make you sound stupid. I read your
> documents. You could at least read other peoples -- but that would
> naturally require that you even realize that other people have done
> work on this topic.

I believe your tone here is less than helful :-(. You weaken your position by
being insulting instead of sticking to the facts.

> > > Even were transport layer security needed, there are many other
> > > protocols for doing the exact same thing -- your solution is hardly
> > > new or interesting. Why not use an existing one instead of rolling Yet
> > > Another One? Of course, as I've repeatedly mentioned, network layer
> > > security is being used by many people today and will be standardised
> > > very soon -- probably before SSL.
> >
> > We never claimed the solution was new or interesting. However, it is a
> > solution.
>
> Yet Another Solution. Why not invent your own internet protocol? After
> all, it would be a "solution".
>
> > You must have missed a line in the spec:
> >
> >          #define SSL_CK_RC4_WITH_MD5                     0x01
> >          #define SSL_CK_RC4_EXPORT40_WITH_MD5            0x02
> >          #define SSL_CK_RC2_CBC_WITH_MD5                 0x03
> >          #define SSL_CK_RC2_CBC_EXPORT40_WITH_MD5        0x04
> >          #define SSL_CK_IDEA_CBC_WITH_MD5                0x05
>
> Gee, I was under the impression that that was CODE, not SPEC.

Another helpful response :-(

> > Not true. Distinguished names can be bulky, but you don't have to
> > use them that way.
>
> What other way could you use?

I would do one of two things:

1. Define a conventional way to use the DN (pick a subset like RFC1485 does).

2. Extend the set of attribute types supported by a DN.

> > They can be made to map into DNS names trivially,
>
> How? Name a single methodology.
>
> > Please define a solution that is:
> >
> > 	distributed
> > 	reliable
> > 	supports an unforgeable name to public-key mapping
> > 	standard
> > 	not-bulky
> > 	not-expensive
> >
> > I will be the first to sign up and buy one. The market exists.
>
> Use DNS for key distribution. Use IPSP (soon to be standardized -- SSL
> isn't standard either) for the packet layer. Use some variant of
> Photuris for key distribution. All the software in question is
> publically available or will be and will run on a wide variety of
> platforms.

Please provide a reference for "Photuris". The web crawler couldn't find it.


-- 
---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp@mcom.com              http://www.mcom.com/people/kipp/index.html