Re: Clarification of my remarks about Netscape

["Amanda Walker" <amanda@intercon.com>]

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

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.

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

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

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.

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

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

> The market will decide one way or the other.

On this I agree completely.


Amanda Walker