From: "Kipp E.B. Hickman" <kipp@warp.mcom.com>
Date: Mon, 12 Dec 94 15:34:05 PST
To: "Amanda Walker" <cypherpunks@toad.com
Subject: Re: Clarification of my remarks about Netscape
In-Reply-To: <9412121811.AA55359@amanda.dial.intercon.com>
Message-ID: <9412121532.ZM17644@warp.mcom.com>
MIME-Version: 1.0
Content-Type: text/plain


On Dec 12,  6:11pm, Amanda Walker wrote:
> Subject: Re: Clarification of my remarks about Netscape
> [I'm sending this to the list because it does have some crypto content]
>
> "Kipp E.B. Hickman" <kipp@warp.mcom.com> writes:
> > > There is no need to bypass existing efforts just to add cosmetic value to
> > > your own software.
>
> > This has nothing to do with security...
>
> Agreed.  My annoyance with Netscape is not based solely, or even primarily,
> on security concerns.  In fact, my only annoyance with your security
> proposal is that it is at the wrong layer (or, more accurately, at layer
> which should be secondary).  In my view, you picked the right technology,
> but applied it to the wrong problem :).
>
> > Clearly I'm an idiot. Explain it to me.
>
> SSL is a mechanism whereby a client and a server can establish a secure,
> authenticated transport channel.  The problem is that this isn't what I want
> to secure and authenticate.  Most of the time, in fact, I don't care about
> the transport: I may be talking through a proxy (like the current CERN
httpd),
> or bringing things in from a cache, or talking to a load-balanced server
> array.  I want the *documents* I'm accessing to be secure and/or
> authenticated.  I want my HTML documents signed and certified by the
*author*,
> not the server.  I couldn't care less about the server if I can verify that
> I've got the right document in response to my query.  Similarly, if I send
the
> contents of a form containing, say, my Amex number, I want to encrypt the
> session key with the public key of the merchant, not the service provider.

I believe that these properties of document security are orthogonal to
transport security. Today we have bit off transport security. Using MIME
multipart encoded documents, document security can be handled as well. There
already exist standards defining the format for these (PEM etc.), all that is
missing is a browser that adheres to them, and some server based tools for
creating them. SSL combined with those provides a powerful solution to todays
Internet problems (jeesh, now *I'm* starting to sound like a marketing person
:)

> This is what I (and many others) mean by an "end to end security model."
> Transport security is a nice secondary ability (it helps defend against
> traffic analysis, for example, and casual snooping by students with packet
> sniffers), but without end-to-end security, it's simply a way of providing a
> false sense of security.  I wouldn't want to do away with the TCP checksum
> field simply because the modem I use for my SLIP link is "error-correcting,"
> and I feel the same way about security.

Agreed. However, today, we consider it a primary concern instead of a secondary
concern. To do business on the Internet, people will be filling in forms and
submitting data that is sensitive to server operators. We don't want that data
to be observered in transit. Data that is paid for should also be private.

> > I put my email address in there for that very reason. Jeesh.
>
> I'd rather that technical feedback occur in a public forum like the IETF.
> I have no pretensions about being a security expert, and I want people to
> shoot down my bad ideas too.  Heck, I *like* having my competitors tell me
> what's wrong with my ideas :).

I tend to agree here, but before I open something up to wide discussion I
prefer to have a smaller group doing the review work. After the small group
work has been done, then a larger review follows.

> > >     This serves as a direct barrier to competition from other commercial
> > >     vendors.
>
> > 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.
>
> Nope, not if I want to sell it (note the word "commercial" in my comment).
> RSAREF cannot be used for commercial software, nor can IDEA under the PGP
> license.  There is no feasible way to license the RSA patents for commercial
> use except by licensing TIPEM.  I have been told this outright by Kurt
> Stammberger of RSADSI (their VP of marketing, I believe).  This is not
> secondhand information.  All commercial software that I know of using RSA
> public key encryption and RSA stream ciphers (such as RC2 and RC4) uses TIPEM
> and BSAFE, including Lotus Notes and Apple PowerTalk.  RSA's royalty
structure
> is based on a percentage of revenue, with the percentage on a sliding scale
> based on gross corporate revenue (not just on products which use RSA's
> patents).  If you keep your margins low to compete in the marketplace, you
> lose.  Even you folks are making your money on high-margin products (servers)
> rather than low-margin ones (clients), I'd wager at least in part because
it's
> a way to make money despite having to pay RSA royalties.

I think RSA pulled a fast one on you. We don't use TIPEM. We wrote the X.509
handling code ourselves and have tested it for interoperability. In any case,
there are two classes of net consumers out there: the academia and corporation.
The academia can almost always get access to source code for free and reuse it
interesting manners with little trouble, as long as it's academic. Us business
types get stuck paying for everything (of course we make a living that way
too...). It doesn't bother me that people would have to license RSA technology
to implement SSL commercially. We did, and in some sense it levels the playing
field.

However, in defense of SSL, I must say that there is no strict requirement for
RSA technology. A careful reading of the spec will lead one to discover that
different public-key technologies can be used. Since certificates are typed,
and standard X.509 certificates include algorithm identifiers, it is possible
to implement a different authentication mechanism that doesn't use RSA
technology.

For example, to choose some popular choices (:^), one could use SHS instead of
MD5, skip-jack instead of RC2/RC4/IDEA and some other freely available public
key algorithm.

> The RSAREF license has been loosened up some recently, but it's still
> restricted to freeware.
>
> > As for a barrier to competition. 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?
>
> I don't have to pay royalties to sell an implementation of TCP/IP.  Your
> analogy fails.

My point was that in order to even play on the internet, one needs a computer,
a network connection, and TCP/IP, *PLUS* all of the various software that one
wishes to use to communicate. This is not free. It is being paid for by you
whether you do it directly, or it is built into the margins of the hardware
manufaturer that sold you the machine.

> > You are somewhat right here. In fact, this was done because we are a
company
> > interested in surviving long enough to withstand the eventual attack
> > by microsoft.
>
> You've already got your eggs in the right basket on this one--sell servers
and
> services, not client software.  Microsoft has a miserable track record in the
> server arena (witness the underwhelming success of Windows NT :)).  It's also
> less of a commodity market, which is where Microsoft excels (no pun
intended).
>
> > As a result we received critical review
> > from some decent members of the crypto community, including:
> >
> > 	Martin Abadi
> > 	Mike Burrows
> > 	Alan Schiffman
> > 	Matt Robshaw
> > 	Burt Kaliski
>
> Mostly RSADSI people, by my count.  Great technical background, but I
wouldn't
> call relying on one of your technology vendors "peer review"...

Actually, 2 people from DEC, one from EIT and 2 from RSA.

> > As for the IETF standards process, we are pushing the
> > document into the RFC process.
>
> Precisely.  Rather than working with others in the industry and research
> communities, you are trying to push your proposal into the standards track.

I'm listening! What is wrong with SSL? What defects does it have in the way
that it tries to solve privacy and authentication? What should we do to make
the next version better?


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