From: “Perry E. Metzger” <perry@imsi.com>
To: “Kipp E.B. Hickman” <kipp@warp.mcom.com>
Message Hash: d7e41ffeb6e2ef35377e4ab63987cbe0ea23d0807aa8353aa83bd6deb384d3e6
Message ID: <9412122322.AA11307@snark.imsi.com>
Reply To: <9412121508.ZM17611@warp.mcom.com>
UTC Datetime: 1994-12-12 23:23:47 UTC
Raw Date: Mon, 12 Dec 94 15:23:47 PST
From: "Perry E. Metzger" <perry@imsi.com>
Date: Mon, 12 Dec 94 15:23:47 PST
To: "Kipp E.B. Hickman" <kipp@warp.mcom.com>
Subject: Re: Clarification of my remarks about Netscape
In-Reply-To: <9412121508.ZM17611@warp.mcom.com>
Message-ID: <9412122322.AA11307@snark.imsi.com>
MIME-Version: 1.0
Content-Type: text/plain
"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.
> 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.
> 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.
> > 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.
> Not true. Distinguished names can be bulky, but you don't have to
> use them that way.
What other way could you use?
> 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.
Perry
Return to December 1994
Return to ““Perry E. Metzger” <perry@imsi.com>”