Re: Clarification of my remarks about Netscape

In article <9412111620.AA41983@eldamar.walker.org>, you write:
> Several people have asked me to clarify my recent comments about Netscape.
> I am more than happy to oblige.
>
> First of all, let me begin by saying that I am a biased observer, and that
> all of this is my personal opinion.  My annoyance with Netscape is also
closer
> to the surface this week than it normally is, due to a variety of factors
> (including having just returned from the San Jose IETF meeting).  My initial
> comment, and the ones that follow in this message, are thus more frank than
is
> my usual style on, say, public Usenet newsgroups.
>
> That being said, here are some of the data that has gone into my impressions
> of Netscape so far.
>
> (1) Netscape plays very fast and loose with HTML.  Rather than participating
>     in the existing standardization efforts, they have indiscriminately added
>     "extensions" to it that are not supported by any other client software,
>     and which in some cases go directly against HTML's markup-oriented
>     structure.  This only adds more confusion to an already muddy area,
>     delays the prospects for a standard HTML specification, and divides the
>     WWW into "WWW Classic" and "Netscape-compatible".  Personally, as a
>     strong proponent of universal interoperability, I find this
reprehensible.
>     There is no need to bypass existing efforts just to add cosmetic value to
>     your own software.

This has nothing to do with security...

> (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? I put my email address in there for that
very reason. Jeesh.

>								  It is also
>     tied directly to the RSA certification hierarchy.  Now, for those of us
>     who have X.509 certificates rooted in the RSA Commercial Certification
>     authority, that's fine, but it also means that any other WWW client that
>     wishes to interoperate with Netscape's "secure servers" must license
>     TIPEM from RSA Data Security, and consequently pay RSA's rather high
>     royalties, unless the software is free (in which case RSAREF can be
used).
>     This serves as a direct barrier to competition from other commercial
>     vendors.  This is not all bad--I happen to like RSADSI's products and
>     technology--but promoting a transport-level security system instead of
>     an end-to-end one is to my mind simply irresponsible.

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

>     There has been no peer review of Netscape's security model--it was simply
>     implemented by fiat, without regard for the IETF standards process.  I
>     find that this leaves a very bad taste in my mouth.  I also heard similar
>     sentiments from a wide variety of other attendees at the IETF, including
>     members of the IP Security working group, people who attended the Secure
>     HTTP BOF, and others.  This leads me to believe that it's not just a
>     matter of me leaping to wild conclusions.

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. Instead of waiting several years before anything was agreed
upon and ending up with a kitchen sink protocol as all others these days
do, we took a simpler approach. And instead of hiding in a closet with
it, we brought it out to light. 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

to name a few. As for the IETF standards process, we are pushing the
document into the RFC process.

> (3) Netscape is viewed as a "loose cannon" by most of the other commercial
>     players in the WWW arena, mainly because they have introduced a fair
>     amount of FUD into the HTML standardization effort, while simultaneously
>     promoting themselves as being standards-based.  Members of Apple's
>     "Cyberdog" project and Microsoft's web projects, who *are* trying to
>     contribute to the standards process, had particularly excoriating things
>     to say in this regard.

This is a matter of opinion. However, I believe that our opinions
don't matter in the long run because of the 800 pound gorilla
Microsoft. They will push something out, it will be proprietary, and
they will name the tune and ask us to play along. Now we can either
just sit back in our current comfy cozy standards based processes and
languish for a few years, and then SIGH and say "Gee wasn't that fun,
too bad microsoft shoved yet another piece of excrement down our
throats" or we can be "loose cannons", get something out there, try it
out and see what happens. The market will decide one way or the other.

> Now, as I said, I am biased and my comments about Netscape are strictly my
> person opinions.  I will be perfectly willing to revise these opinions as I
> receive more data.  For example, if Netscape takes a more active part in
> the standards process, works with RSA to secure wider availability of the
> underlying technology required by their proposals, and generally demonstrates
> a willingness to play nicely with other children, that would be great, and
> I'll just as strongly defend them as I am panning them now.
>
> However, in my view, they have not shown a good initial track record.
> Only time will tell.
>
>
> Amanda Walker
> InterCon Systems Corporation
>
>
---------------------------------------------------------------------
Kipp E.B. Hickman          Netscape Communications Corp.
kipp@mcom.com              http://www.mcom.com/people/kipp/index.html


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

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

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

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

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

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

.pm

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

"Kipp E.B. Hickman" says:
> 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.

First of all, Mr. Hickman, you might notice that I said that
encryption is needed for privacy. However, transport layer security is
far from sufficient for the web because it DOES NOT SECURE THE
DOCUMENTS. The fact that you mention email and SSL in the same
paragraph demonstrates an ignorance of this topic. Because email is
store and forward transport layer encryption mechanisms are worthless
-- they only say that no one could read the last hop and in no way do
they secure the documents themselves. Thats why PEM was
developed. There is now a merger of PEM and MIME that is soon going to
be a proposed internet standard following the last IETF meeting.

Indeed, Mr Hickman, had you and your friends at Netscape been paying
attention instead of rolling your own, you might have noticed that
IPSP prototypes are around TODAY and that transport layer mechanisms
are going to become rapidly obsolete for securing the communications
themselves. You can find a version of swIPe, which is not quite IPSP
but is fairly similar (and which is being hacked on so that it will
conform) on ftp.csua.berkeley.edu; its even modloadable on Suns. Thats
available TODAY.

> In some future land where IPNG or it's cousin's appear, then maybe
> SSL will be unnecessary.

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.

> Finally, the system is perfectly usable in a proxy environment.

Sheer ignorance. In your system I must trust each and every hop
between myself and the document, and I must also trust all the
servers. With public key signatures on the documents themselves, as
Amanda Walker mentioned, you then need trust nothing at all in order
to know that documents are authentic.

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

I'm afraid that your technology is the old one, and as for "putting
something out", as I mentioned network layer solutions are available
for ftp TODAY. In source form. Immediately. Oh, and by the way, they
don't incorporate such useless abortions as 40 bit RC4 keys.

> We have made the protocol public instead of propreitary

IPSP is also public. So what?

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

We also loathe CLNP. Do you propose to do all your network layer
communications over CLNP because it, too, is an ISO standard? ISO
standards are universally loathed in the internet community -- and for
good reasons. Lets take X.509 as one example.

X.509 is tied into X.500 distinguished names. They are

1) Bulky
2) Do not map into DNS names
3) Cannot be mapped into the DNS.
4) Do not support the web of trust model.
5) Are difficult to build parsers for
6) Require bulky and often expensive X.500 directory systems to use
   effectively.

> You are whining.

No, I am correct. You are ignorant of the community you are working with.

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

I'm afraid the larger picture has been solved -- you just haven't been
the ones solving it and you haven't been paying attention to the
other people doing work in this area.

> Discussions about how to do this are welcome. Using DNS style
> technology sounds like a good place to start.

Perhaps if you guys had bothered to attend some of the security area
meetings at an IETF or two and read up on existing art you would have
already known about this topic.

> In addtion, discussing how to solve the "DNS" problem would be
> profitable for all.

The solution is easy -- don't use X.509 certificates.

Perry

On Dec 12,  5:42pm, Perry E. Metzger wrote:
> Subject: Re: Clarification of my remarks about Netscape
>
> "Kipp E.B. Hickman" says:
> > 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.
>
> First of all, Mr. Hickman, you might notice that I said that
> encryption is needed for privacy. However, transport layer security is
> far from sufficient for the web because it DOES NOT SECURE THE
> DOCUMENTS. The fact that you mention email and SSL in the same
> paragraph demonstrates an ignorance of this topic. Because email is
> store and forward transport layer encryption mechanisms are worthless
> -- they only say that no one could read the last hop and in no way do
> they secure the documents themselves. Thats why PEM was
> developed. There is now a merger of PEM and MIME that is soon going to
> be a proposed internet standard following the last IETF meeting.

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. Solving this currently
widespread problem makes the Internet a friendlier place for commerce. It
allows sensitive information to be transported privately. Protecting against
forgery is the next logical step.

> Indeed, Mr Hickman, had you and your friends at Netscape been paying
> attention instead of rolling your own, you might have noticed that
> IPSP prototypes are around TODAY and that transport layer mechanisms
> are going to become rapidly obsolete for securing the communications
> themselves. You can find a version of swIPe, which is not quite IPSP
> but is fairly similar (and which is being hacked on so that it will
> conform) on ftp.csua.berkeley.edu; its even modloadable on Suns. Thats
> available TODAY.

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

So who can I talk to? Name one router that speaks the secure protocols you are
documenting? Name one PPP based bridge that does? Show me, today, what
percentage of the Internet is covered by these standards? Give me some growth
curves showing how the Internet will quickly be converted to a secure network?

My point is not that IPSP is "bad". My point is that *today* it is irrelevant.
Tommorow is another matter.

In the future, I hope that you are right, IPSP is everywhere and we can all
breath a sigh of relief. In this case SSL is of little value. However, in the
mean time we have what we have. My company's network hardware is typical. It is
filled with expensive devices that don't understand IPSP or IPNG. In fact, most
of the world is constructed this way. What you are implicitly asking for is for
 the world to replace its networking hardware/software solutions before
allowing privacy. I think that this is a incorrect. SSL is a temporary solution
to a nagging problem. It's design was predicated on the belief that the future
is in protocols such as IPSP. Security will be pushed lower and lower until it
is omnipresent.

> > In some future land where IPNG or it's cousin's appear, then maybe
> > SSL will be unnecessary.
>
> 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.

> > Finally, the system is perfectly usable in a proxy environment.
>
> Sheer ignorance. In your system I must trust each and every hop
> between myself and the document, and I must also trust all the
> servers. With public key signatures on the documents themselves, as
> Amanda Walker mentioned, you then need trust nothing at all in order
> to know that documents are authentic.

You are making the assumption that the proxy is able to understand the secure
conversations between a client and its eventual server. This need not be true
and should not be true.

> > 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.
>
> I'm afraid that your technology is the old one, and as for "putting
> something out", as I mentioned network layer solutions are available
> for ftp TODAY. In source form. Immediately. Oh, and by the way, they
> don't incorporate such useless abortions as 40 bit RC4 keys.

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

Note the inclusion of plain RC4 (not 40 bit), plain RC2 (not 40 bit) and plain
IDEA (again, not 40 bit).

If you have an exportable solution that can be manufactured in the US and then
shipped overseas, then that is something of value. Complaining about 40 bit
keys is not of value. The ITAR rules are what they are and at this point in
time we can't change them.

> > We have made the protocol public instead of propreitary
>
> IPSP is also public. So what?
>
> > > > >	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?
>
> We also loathe CLNP. Do you propose to do all your network layer
> communications over CLNP because it, too, is an ISO standard? ISO
> standards are universally loathed in the internet community -- and for
> good reasons. Lets take X.509 as one example.
>
> X.509 is tied into X.500 distinguished names. They are
>
> 1) Bulky
> 2) Do not map into DNS names
> 3) Cannot be mapped into the DNS.
> 4) Do not support the web of trust model.
> 5) Are difficult to build parsers for
> 6) Require bulky and often expensive X.500 directory systems to use
>    effectively.

Not true. Distinguished names can be bulky, but you don't have to use them that
way. They can be made to map into DNS names trivially, and because you don't
have to have a single root, a web of trust is perfectly possible. Examine how
PGP self signed public keys are managed. Finally, "bulky and often expensive"
is a matter of opinion.

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.



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

"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

On Dec 12,  6:22pm, Perry E. Metzger wrote:
> Subject: Re: Clarification of my remarks about Netscape
>
> "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.

SSL does not provide solutions for the class of problems elucidated by
store-and-forward mail systems. However, it does promise that the transmission
between two mail agents will be private. Depending on the configuration of your
network this may be all you need. Using SSL to "privatize" SMTP transmissions
seems useful to me. If the data being transmitted were PEM then all the better.

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

Something somewhere has to be able to speak IPSP. Something must be changed,
even if it's just software. If it is just software, then I have an upgrade
problem because in our network we have one machine from every workstation
manufaturer and every kind of PC and MAC imaginable. This is not uncommon, and
is a logistics nightmare. Once a service is relegated to only allowing private
communications, you are just as stuck as we are. There will be a class of
hardware/software that cannot communicate.

This upgrade problem exists no matter what security technology is used.

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

I believe your tone here is less than helful :-(. You weaken your position by
being insulting instead of sticking to the facts.

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

Another helpful response :-(

> > Not true. Distinguished names can be bulky, but you don't have to
> > use them that way.
>
> What other way could you use?

I would do one of two things:

1. Define a conventional way to use the DN (pick a subset like RFC1485 does).

2. Extend the set of attribute types supported by a DN.

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

Please provide a reference for "Photuris". The web crawler couldn't find it.


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

In article <9412121600.ZM17661@warp.mcom.com>,
Kipp E.B. Hickman <kipp@warp.mcom.com> wrote:
>> 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.
>
>Please provide a reference for "Photuris". The web crawler couldn't find it.

While you're at it please do my job for me too Perry.

Kipp E.B. Hickman <kipp@warp.mcom.com> wrote:

   Please provide a reference for "Photuris".

Ah, the hazards of not going to IETF...

Eric

-----BEGIN PGP SIGNED MESSAGE-----

It is nice to have a lot of people on the list from Netscape.
Here is a question about SSL relating to the use of certificates:

          + The issuer name must resolve to a name that is deemed
            acceptable by the application using SSL. How the application
            using SSL does this is outside the scope of this memo.

What does Netscape actually do about this?  If I want to make a server
which will interoperate with existing Netscape clients what kind of
certificate do I need, and what kind of name should be in there?
Thanks -

Hal Finney
hfinney@shell.portal.com

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLu1NOxnMLJtOy9MBAQGItwIAr4eerI+FSmPpOIcwITepnXzcUUFkPwsK
+Rz2FC4Y6hV0HoDEt1JnpvCPVV5N74Jtc9xMmF8CcRlBybk25PkxVQ==
=LOql
-----END PGP SIGNATURE-----

I've tried really hard to stay out of this, but this one is just too much.

The question is about IPSP, the swIPe-like IP level security protocol.

   From: "Kipp E.B. Hickman" <kipp@warp.mcom.com>

   Name one router that speaks the secure protocols you are
   documenting? Name one PPP based bridge that does? Show me, today,
   what percentage of the Internet is covered by these standards?

   [ ... later ... ]

   My company's network hardware is typical. It is filled with
   expensive devices that don't understand IPSP or IPNG. In fact, most
   of the world is constructed this way.

The protocol does IP-within-IP encapsulation, which means that every
single router deployed is able to carry the secured traffic.

Now, this is not so egregious an error by itself (it is, but I'm being
polite), but coupled with the claims that SSL is better than anything
else out there, I see an argument from chauvinism rather than one from
knowledge.

Since IPSP works at the IP level rather than at the TCP level there
are protocol stacks that have to change.  This is not immediate.  It
may be that IPSP is not the quickest or best way to link security, but
that is not the point I am making here.  The original denial of IPSP's
potential utility was made in complete ignorance, ignorance so great
to lack even the most basic understanding of the subject at hand.

I cannot trust abbreviated arguments from such a source.  I can,
however, examine ones which are complete and well thought out and
demonstrate some understanding of tradeoffs.

Eric

"Kipp E.B. Hickman" says:
> If you would like we can send you some brouchures for our
> products in that area.
> 

Ah, it doesn't work with existing proxies, so we have to pay
you. Whether it is your true motivation true or not, this 
apparent attempt to create a market for proprietary goods by 
disrupting standards is at the core of the bad odor that your 
company is giving off these days.

Not to mention the arrogance:

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

I'm the first one to agree that even the IETF _can be_ slow and 
cumbersome. But it is a far cry from typical standards bodies
(e.g. ITU, which I've had to deal with recently) in that it is
very easy to participate, the standards are freely available, 
and the process moves fairly rapidly, especially by comparison.

If you want to try to answer "what is the Internet?", more than
anything else it is a set of _standards_ for doing things in
a network of networks. When you declare standards changes by
fiat _without even an attempt_ to work with others (formally
or informally) you are going to irritate not just your competitors 
but your potential customer base (which I'm a part of.)

As a corporate culture, you folks from Netscape seem to project 
a sense of arrogance and disregard for the net culture that is
extremely irritating. And this is from someone who basically
_likes_ your product, and has happy users using it, although I've 
bumped up the priority of checking out the other commercial 
offerings in this area because of your arrogance and total 
disregard for even pro-forma cooperation with the standards process.

I'd also like to point out that, more often than not, attempts
to create proprietary "standards" by fiat don't work. To wit,
look at Microsoft's various attempts at networking.
This company has billions, and it ends up announcing, as a great
"innovation" that it is (finally) going to support TCP/IP in a
meaningful way, despite numerous abortive attempts at other
"standards". 

You point to some other technical areas where frustrated 
manufacturers split off and extended standards, but I think 
you'll find in almost every case that it was _after_ they 
had hit meaningful roadblocks with their proposed standard,
and that they worked dilligently to ensure compatability
amongst themselves and others offering the new level of
technology.  Given the history of your company, and the 
attitudes displayed here, I question whether this will 
happen with your hacks^H^H^H^H^Hextensions.

Doug

On Dec 12,  5:51pm, Doug Barnes wrote:
> Subject: Re: Clarification of my remarks about Netscape
>
> "Kipp E.B. Hickman" says:
> > If you would like we can send you some brouchures for our
> > products in that area.
> >
>
> Ah, it doesn't work with existing proxies, so we have to pay
> you. Whether it is your true motivation true or not, this
> apparent attempt to create a market for proprietary goods by
> disrupting standards is at the core of the bad odor that your
> company is giving off these days.

You are right. It doesn't work with existing proxy's. But existing proxy's
can't do secure data transfers, so what's your point?

> Not to mention the arrogance:
>
> > 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.
> >
>
> I'm the first one to agree that even the IETF _can be_ slow and
> cumbersome. But it is a far cry from typical standards bodies
> (e.g. ITU, which I've had to deal with recently) in that it is
> very easy to participate, the standards are freely available,
> and the process moves fairly rapidly, especially by comparison.
>
> If you want to try to answer "what is the Internet?", more than
> anything else it is a set of _standards_ for doing things in
> a network of networks. When you declare standards changes by
> fiat _without even an attempt_ to work with others (formally
> or informally) you are going to irritate not just your competitors
> but your potential customer base (which I'm a part of.)
>
> As a corporate culture, you folks from Netscape seem to project
> a sense of arrogance and disregard for the net culture that is
> extremely irritating. And this is from someone who basically
> _likes_ your product, and has happy users using it, although I've
> bumped up the priority of checking out the other commercial
> offerings in this area because of your arrogance and total
> disregard for even pro-forma cooperation with the standards process.
>
> I'd also like to point out that, more often than not, attempts
> to create proprietary "standards" by fiat don't work. To wit,
> look at Microsoft's various attempts at networking.
> This company has billions, and it ends up announcing, as a great
> "innovation" that it is (finally) going to support TCP/IP in a
> meaningful way, despite numerous abortive attempts at other
> "standards".
>
> You point to some other technical areas where frustrated
> manufacturers split off and extended standards, but I think
> you'll find in almost every case that it was _after_ they
> had hit meaningful roadblocks with their proposed standard,
> and that they worked dilligently to ensure compatability
> amongst themselves and others offering the new level of
> technology.  Given the history of your company, and the
> attitudes displayed here, I question whether this will
> happen with your hacks^H^H^H^H^Hextensions.

Seems like your mailer was having some difficulty :-)

In any case, my personal opinion is that NCOM is being attacked with a
catch-22. If we had kept the protocol proprietary, then we would have been
shot. We went public with it and are getting shot. If we had waited the 2.5
years to develop it, as a few here would seem to be advocating, then the market
would shoot us.

Nice place to live.


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

> Doug B.:
> >
> > Ah, it doesn't work with existing proxies, so we have to pay
> > you. Whether it is your true motivation true or not, this
> > apparent attempt to create a market for proprietary goods by
> > disrupting standards is at the core of the bad odor that your
> > company is giving off these days.
> 

Kipp:
> You are right. It doesn't work with existing proxy's. But existing proxy's
> can't do secure data transfers, so what's your point?

Rather than saying, "oh, our new 'standard' won't work with 
existing technology, so buy ours", you might say, "we will be
happy to work with the developers of existing proxies to make
necessary changes to be compatible with our product. Alternatively,
you could buy our proxy software which also has some additional
benefits of foo, bar and baz."  (Also, not every solution to
every Web security threat involves breaking existing proxies.)

But no, you blindly forge ahead, so full of yourself that you 
blissfully reinvent wheels (Perry), miss the real concerns of 
the users (Me), disrupt the marketplace (Amanda), and generally 
fail to think things through very well (Adam) or consider the work
of others (Perry).

Your three biggest problems are: arrogance, arrogance and 
arrogance.

Kipp:
> In any case, my personal opinion is that NCOM is being attacked with a
> catch-22. If we had kept the protocol proprietary, then we would have been
> shot. We went public with it and are getting shot. If we had waited the 2.5
> years to develop it, as a few here would seem to be advocating, then the market
> would shoot us.
> 

If you were willing to _read_ and to go to an occasional 
meeting, or even send out a post, "Hey, I'm about to sink
the resources of this company into coming up with yet another
transport layer security protocol, anyone got one already?",
then you might get less hostility, or you might not get used
for target practice so often.

On Dec 12,  6:26pm, Doug Barnes wrote:
> Subject: Re: Clarification of my remarks about Netscape
> > Doug B.:
> > >
> > > Ah, it doesn't work with existing proxies, so we have to pay
> > > you. Whether it is your true motivation true or not, this
> > > apparent attempt to create a market for proprietary goods by
> > > disrupting standards is at the core of the bad odor that your
> > > company is giving off these days.
> >
>
> Kipp:
> > You are right. It doesn't work with existing proxy's. But existing proxy's
> > can't do secure data transfers, so what's your point?
>
> Rather than saying, "oh, our new 'standard' won't work with
> existing technology, so buy ours", you might say, "we will be
> happy to work with the developers of existing proxies to make
> necessary changes to be compatible with our product. Alternatively,
> you could buy our proxy software which also has some additional
> benefits of foo, bar and baz."  (Also, not every solution to
> every Web security threat involves breaking existing proxies.)

If this hadn't been made clear already, then hopefully this will:

	Our intention is to support any development effort attempting
	to implement an SSL conformant implementation. We will work with
	you to repair the spec as needed to eliminate any errors or
	ommisions, and help you test your implementation to ensure that
	it interoperates with ours.

> But no, you blindly forge ahead, so full of yourself that you
> blissfully reinvent wheels (Perry), miss the real concerns of
> the users (Me), disrupt the marketplace (Amanda), and generally
> fail to think things through very well (Adam) or consider the work
> of others (Perry).
>
> Your three biggest problems are: arrogance, arrogance and
> arrogance.

I'm really sorry that this is how we are currently being perceived. It was
never our intention. Rather, we wished to do those things that we believed were
necessary to allow commerce on the Internet. We are a small company with
limited resources and limited time to market. After talking with prospective
customers we came up with a plan and implemented it. We are sorry if somebody's
toes were stepped on in the process.

> Kipp:
> > In any case, my personal opinion is that NCOM is being attacked with a
> > catch-22. If we had kept the protocol proprietary, then we would have been
> > shot. We went public with it and are getting shot. If we had waited the 2.5
> > years to develop it, as a few here would seem to be advocating, then the
market
> > would shoot us.
> >
>
> If you were willing to _read_ and to go to an occasional
> meeting, or even send out a post, "Hey, I'm about to sink
> the resources of this company into coming up with yet another
> transport layer security protocol, anyone got one already?",
> then you might get less hostility, or you might not get used
> for target practice so often.

We believe that we were up to date with respect to what was going on in the
internet community at large when the company was started. Somebody should feel
relieved that approach matches where the internet seems to be heading -
security at the transport levels.

Our imperfect examination of the work in progress yielded nothing that would
meet our needs and our timelyness. I'm sorry if our selection criteria don't
meet yours.

In any case, the cat is out of the bag, and we are where we are.

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

From: "Kipp E.B. Hickman" <kipp@warp.mcom.com>

   If this hadn't been made clear already, then hopefully this will:

	   Our intention is to support any development effort attempting
	   to implement an SSL conformant implementation. We will work with
	   you to repair the spec as needed to eliminate any errors or
	   ommisions, and help you test your implementation to ensure that
	   it interoperates with ours.

It's clear to me.  "We're going to use some security, as long as it's
called SSL and our authorship is on the document."

Eric

Someone who has never produced a really cool piece of software
that brings crypto to the masses wrote:

> > But no, you [Netscape] blindly forge ahead, so full of yourself that you
> > blissfully reinvent wheels (Perry), miss the real concerns of
> > the users (Me), disrupt the marketplace (Amanda), and generally
> > fail to think things through very well (Adam) or consider the work
> > of others (Perry).
> >
> > Your three biggest problems are: arrogance, arrogance and
> > arrogance.

Kipp E.B. Hickman writes
>
>       [Netscape's] intention is to support any development effort attempting
>       to implement an SSL conformant implementation. We will work with
>       you to repair the spec as needed to eliminate any errors or
>       ommisions, and help you test your implementation to ensure that
>       it interoperates with ours.

Guys, this is the greatest news.

How come the cypherpunks list is not singing and dancing and
saying how great this is, instead of whining and bitching
because Netscape is not all the way there yet.



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

"Kipp E.B. Hickman" says:
> In any case, my personal opinion is that NCOM is being attacked with
> a catch-22. If we had kept the protocol proprietary, then we would
> have been shot. We went public with it and are getting shot. If we
> had waited the 2.5 years to develop it, as a few here would seem to
> be advocating, then the market would shoot us.

This is a false dichotomy -- there are far more possibilities than
that. I pillory you not for being non-public but for being
non-intelligent. You could have bothered to read the literature and
designed something useful given an understanding of what came before
(your naive notion that somehow IPSP might require router
modifications would have been dispelled had you bothered to spend the
half hour needed to read and understand the proposals) or you could
have gone to the IETF and gotten everything done very fast if you'd
bothered to use the system right. As it stands you come off looking
like ignorant blunderers.

.pm

Perry E. Metzger writes
> As it stands [netscape] come off looking
> like ignorant blunderers.

Perry, you are wrong.

Now Netscape have done a lot of silly stuff.  It is painfully
obvious that they developed Netscape for windows without
using debug windows, and as a result Netscape crashes my
system continuously.

But reality is that they have produced by far the coolest browser
there is, and they are bringing crypto to the masses, and you,
and Eric Hughes, and most of us, have not yet brought crypto
to the masses.

Give them credit for doing what we have talked of doing, but
have not actually done.

Sure, if you had done it, the crypto would be better.  If 
I had done it, it would not crash all the time and its
caching algorithm would be way superior.

But I did not do it and you did not do it.  They did it.

Perhaps they will fix the crashing in version 1.1, and
the crypto and the caching in version 1.2


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

James A. Donald says:
> But reality is that they have produced by far the coolest browser
> there is, and they are bringing crypto to the masses, and you,
> and Eric Hughes, and most of us, have not yet brought crypto
> to the masses.
> 
> Give them credit for doing what we have talked of doing, but
> have not actually done.

You claim we haven't done anything and Netscape has.

ftp.csua.berkeley.edu has the swIPe code sitting right on it.

Its being deployed by TIS in their new firewall products, and is being
used by others. I could have conducted the full PR campaign to get
people using it, but have chosen not to because I don't want to have
to later sell them on an (incompatible) IPSP packet format (which is
superior). I'm already working on hacking swIPe into IPSP.

Netscape looks foolish because they don't bother to look at other
people's work. I won't comment on you.

Perry

> 
> 
I wrote:
> > But reality is that they have produced by far the coolest browser
> > there is, and they are bringing crypto to the masses, and you,
> > and Eric Hughes, and most of us, have not yet brought crypto
> > to the masses.

Perry E. Metzger writes
> You claim we haven't done anything and Netscape has.

Not what I claimed.

> 
> ftp.csua.berkeley.edu has the swIPe code sitting right on it.
> 
> Its being deployed by TIS in their new firewall products

I claimed you have not deployed crypto to the masses and they
have.  I did not claim that you have not deployed crypto and
and they have.


I am sick of you misrepresenting what I say, and I am sick of Eric
misrepresenting what I say.

Cut it out.



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

-----BEGIN PGP SIGNED MESSAGE-----

"Perry E. Metzger" <perry@imsi.com> writes:

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

I was going to say that an SSL-aware proxy daemon could play "man in
the middle" and pass through the SSL handshaking messages which occur
at connection time, so that the user client could authenticate the
remote server, then communicate using a key shared with that server but
which the proxy would not know.

But that won't work with SSL, I guess.  The SSL handshaking goes on
before any message data has been exchanged; in particular, before the
URL is sent to the proxy to tell it what server to connect to.  (Hiding
URL's is one of the features of SSL.) So in fact with SSL the only
authentication possible is between proxy and user, and then between
proxy and remote server.  There doesn't seem to be a place in the
protocol where the user could authenticate the remote server and create
a key which would not be known to the proxy.  This does seem to be a
deficiency.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLuzO1hnMLJtOy9MBAQG+IgIAyZvvTpXB6dmCbEyrvLA65QeK4c5T8UNi
NAelFrZMEsb/NdS2l8ApczkljEnviCpOiV9W5ALYTKXr9nzJbSaZbg==
=eBkX
-----END PGP SIGNATURE-----

In article <199412122229.OAA05451@jobe.shell.portal.com>, you write:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> "Perry E. Metzger" <perry@imsi.com> writes:
> 
> >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.
> 
> I was going to say that an SSL-aware proxy daemon could play "man in
> the middle" and pass through the SSL handshaking messages which occur
> at connection time, so that the user client could authenticate the
> remote server, then communicate using a key shared with that server but
> which the proxy would not know.
> 
> But that won't work with SSL, I guess.  The SSL handshaking goes on
> before any message data has been exchanged; in particular, before the
> URL is sent to the proxy to tell it what server to connect to.  (Hiding
> URL's is one of the features of SSL.) So in fact with SSL the only
> authentication possible is between proxy and user, and then between
> proxy and remote server.  There doesn't seem to be a place in the
> protocol where the user could authenticate the remote server and create
> a key which would not be known to the proxy.  This does seem to be a
> deficiency.

First, let me clarify slightly. The only place where a problem occurs
currently is if the server is attempting to authenticate the client.
Because the proxy agent cannot reliably act as an agent for a client,
it cannot properly answer a servers authentication requests.

I can imagine several solutions to this thorny problem:

1. Client connects securely to a proxy agent using SSL. Upon
   establishment of the secure connection, the request is transmitted to
   the proxy. If the request is to a secure document (the proxy can tell
   by examining the URL) (and the client can tell), then the client
   re-enters the SSL handshake protocol from the start and the proxy
   agent turns into a data forwarder ala sockd.

   This is technically a change to the proxy protocol, but requires no
   change to the SSL protocol. Of course, to teach proxies about security
   requires *some* change...

2. The client connects insecurly to a proxy agent using current
   methods. The client requests a secure document. The proxy agent
   connects to the secure server using SSL and attempts to act as the
   client's agent in the transaction. Note that the user must consider
   this an insecure connection, and trust it only as far as she/he trusts
   the proxy server.

   Most of the time, the proxy will work. However, when client authentication
   is performed, the proxy fails as it should. If one were to construct a
   "trusted" proxy, then in theory it could perform the client authentication,
   acting as an agent for the client. However, this seems kinda scary to me,
   so I can't say I recommend it. To do this would require the client to
   transmit its authentication information to the proxy agent, which seems
   like a really bad idea.

3. SSL has a notion of a "security escape" of which there are currently no
   applications. One could define a security escape to allow enveloping of
   the authentication information needed by the final server so that the
   client can properly respond to authentication requests. I haven't thought
   this thru yet.

-----BEGIN PGP SIGNED MESSAGE-----

"Kipp E.B. Hickman" <kipp@warp.mcom.com> writes:

>In article <9412111620.AA41983@eldamar.walker.org>, [Amanda Walker] writes:

>>								  It is also
>>     tied directly to the RSA certification hierarchy.  Now, for those of us
>>     who have X.509 certificates rooted in the RSA Commercial Certification
>>     authority, that's fine, but it also means that any other WWW client that
>>     wishes to interoperate with Netscape's "secure servers" must license
>>     TIPEM from RSA Data Security, and consequently pay RSA's rather high
>>     royalties, unless the software is free (in which case RSAREF can be
>used).
>>     This serves as a direct barrier to competition from other commercial
>>     vendors.  This is not all bad--I happen to like RSADSI's products and
>>     technology--but promoting a transport-level security system instead of
>>     an end-to-end one is to my mind simply irresponsible.

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

What about the certification aspect?  Would servers be forced to pay
for an RSA key certification?  This was a point I raised in my comments
on SSL.  PEM's reliance on the RSA-based certification hierarchy has at
least slowed its progress if not doomed it altogether.

I understand that Netscape clients will embed certain Certification
Authority keys and use them to validate signed server keys.  Does this
also mean that only RSA-approved CA's will be allowed?  What if some CA
in some other country not covered by RSA patents came into operation?
Would your relationships with RSA still allow you to embed non-RSA-
approved CA keys?  I would hope so.  RSA is both respected and mistrusted
in the crypto community, so you wouldn't want to tie yourselves too
closely to them.

Have you heard of the "web of trust" concept implemented by PGP?
This allows users to designate chosen individuals as trusted key signers
and to authenticate keys on that basis.  It is non-hierarchical and
decentralized. (There is also plenty of bad blood between RSA and PGP.)
Will you be able to support decentralized authentication models like this?
I hope this is something you will explore.

(I have no financial interests in any of these companies or protocols!)

Hal Finney

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLuzMQRnMLJtOy9MBAQEoyQH8CvFo2PzdB7fzn5TDSW52mZFpuu2HIt9d
YazndhCPcE349CxumMzwmrE9tVA9e/toEIysfSwcjubW1rOXX7Wrxw==
=189c
-----END PGP SIGNATURE-----