From: "Kipp E.B. Hickman" <kipp@warp.mcom.com>
Date: Mon, 12 Dec 94 13:59:36 PST
To: perry@imsi.com
Subject: Re: Clarification of my remarks about Netscape
In-Reply-To: <9412122118.AA11047@snark.imsi.com>
Message-ID: <9412121357.ZM17505@warp.mcom.com>
MIME-Version: 1.0
Content-Type: text/plain


On Dec 12,  4:18pm, Perry E. Metzger wrote:
> Subject: Re: Clarification of my remarks about Netscape
>
> "Kipp E.B. Hickman" says:
> > > (1) Netscape plays very fast and loose with HTML.
> >
> > This has nothing to do with security...
>
> No, but its a Bad Thing.
>
> > > (2) The Netscape Secure Sockets proposal has an extremely poor security
> > >  model.
> > >     It is not an end-to-end security model, but rather relies on
transport
> > >     level security, which is in my view dangerously inadequate for
reasons
> > >     which should be obvious to most of the folks on this list.
> >
> > Clearly I'm an idiot. Explain it to me. And while you are at it, why
> > don't you email me your comments on the spec?
>
> HTTP, like SMTP, is only a transport for underlying documents. The
> underlying documents are the things people wish to secure, not the
> transport layer.  By securing only the transport, you make it possible
> for people to get pages that are forged, although they can be sure of
> what machine delivered them (which isn't significant). Your system is,
> for instance, useless in a proxy HTTP daemon environment.
>
> Actually, securing the communications as well is important for
> privacy, but that should be done via IPSP, not some new, incompatible,
> mechanism.

I disagree compeltely. First of all, lets start with "not wanting to secure the
transport layer". Right now email, passwords, etc. can be read off of the
internet in the clear providing no measure of privacy at all. I believe the SSL
protocol solves this problem. In some future land where IPNG or it's cousin's
appear, then maybe SSL will be unnecessary. At the rate that is going, we can
use SSL for the next 10 years. Finally, the system is perfectly usable in a
proxy environment. If you would like we can send you some brouchures for our
products in that area.

Secondly, SSL is not an end, but a beginning. Instead of waiting 10 more years
before the standards process gets around to inventing some old technology and
codifying it, we have put something out. We have made the protocol public
instead of propreitary and we have asked for critical review. Not griping.

Securing documents themselves is a second thing that security software can try
to tackle. However, what most people seem to miss is that document security is
orthogonal to transport security. We have addressed transport security.
Document security can be handled in several ways, including using digital
signatures. Because HTTP supports MIME multi-part encoded data using standard
RFC-822 headers, it is possible for signed data to be transported today with no
change to HTTP whatsoever. Most people out there haven't done this. We will.
Today it is already true that documents could be stored mime encoded with
digital signatures. All that is needed is a browser that can notice it and put
some information up.


> > >	It is also
> > >     tied directly to the RSA certification hierarchy.
>
> I'll point out that X.509 is widely loathed in the internet community
> -- its X.509 that caused PEM to fall flat on its face and die.

Loathed for what reason? Because it's a standard? You are being two-faced about
this thing you know. We chose standards where standards were readily available.
X.509 is a perfectly usable way for performing authentication. If you disagree,
may I suggest you examine:

	http://bs.mit.edu:8001/ipra.html

> > This is an outright lie. We don't use TIPEM. You could build a
> > conformant SSL implementation using RSAREF and the freeware IDEA
> > cipher code. As for a barrier to competition.
>
> RSAREF versions of the code can't be used commercially. RSA won't
> license people to do stuff on their own -- unless you have significant
> pull, you have to buy TIPEM or BSAFE from them and use THEIR code.

You are whining. Provide a free, publicly available public-key algorithm that
is not patented, and can be used world wide with exportability from the US.
Then we will use it. Until then we are stuck, just like everyone else, in using
what is available, not what is imagined.

> > So what else is new? We
> > all have barriers to overcome before we can compete. Should we get rid of
> > TCP/IP as a barrier to using the web?
>
> Well, TCP/IP is available for free, but thats a horse of a different
> color. I don't particularly like your security model, but I don't
> object that strenuously to your use of TIPEM qua TIPEM. I do strongly
> object to X.509, which is based on technologies entirely alien to the
> internet. How do I look up an X.509 certificate in the DNS? Now, given
> the Eastlake and Kaufman DNS security system, you can put keys in the
> DNS if you use DNS names, but X.509 uses abortive ISO distinguished
> names which are utterly unmappable into the DNS.

Now this is a good point. This is the kind of space that the internet is
heading into. How does authentication work in the larger scheme? We at Netscape
have tackled a small piece of the problem space. But the larger picture remains
unsolved. Discussions about how to do this are welcome. Using DNS style
technology sounds like a good place to start.

> As for your "peer review", I'll note that it was done extensively by
> RSADSI folks, who aren't entirely unbiased about technologies...

Last I checked Mike Burrows and Martin Abadi worked for DEC at SRC in Palo
Alto. They were the primary reviewers and contributed greatly to the revisions
noted at the front of the document.

-----

It would be much more satisfying to be having a technical discussion of SSL's
merits or flaws. In addtion, discussing how to solve the "DNS" problem would be
profitable for all.



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