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.

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

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

Kipp E.B. Hickman writes:

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

	The first thing you need to do is define a threat model.  Make
explicit your assumptions.  What needs to be trusted, and when?  Who
are your threats?  What are your assets, and what are they worth?

	Next, you should publish the model, and let us rip it into
little shreds.  This is hard on the ego, but good for your threat
model.  No one ever thinks of everything.  Iterate here.  This is
where the time & effort belong.

	Once you have a solid threat model, you should see what
protocols and tools are out there that can be used to defend against
those threats.  I suspect that most of the tools you will find you
need exist.  Some will not.

	Having found what wheels don't need to be invented, you need to
code your solutions.  Then you need to publish that code to allow the
security community to decide whether or not to trust it.


Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume

Amanda Walker criticezes SSL because it is irrelevant to
the threat that people are likely to be concerned about.

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

This seems a very relevant criticism:  Has Amanda, or anyone else
proposed an extension to HTML that would incorporate such things?

for example:

<ENCRYPT ALG=soandso PUBLICKEY=87hfkjjhfd98uyeuihdhiucschhuichcxzcxhjcxjlcx
fkfdhfhjdhjkvcccv3454DFFl l79*79 y978yy98gk gkghgksdghsdkghasdsak>
Encrypted and possibly signed material.
</ENCRYPT ALG=soandso SIG=3489347893uisdjhkfdy897r4hf893r4hjf>

(with any special html characters, such as '<' and '>', being escaped
in the ascii armored bitstreams.

Or did the standards groups that Netscape has been ignoring not
bother to discuss such matters?




-- 
 ---------------------------------------------------------------------
We have the right to defend ourselves and our
property, because of the kind of animals that we        James A. Donald
are.  True law derives from this right, not from
the arbitrary power of the omnipotent state.            jamesd@netcom.com