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
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
On Dec 12, 4:18pm, Perry E. Metzger wrote: 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
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
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
-----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-----
participants (8)
-
anonymous-remailer＠xs4all.nl -
db＠Tadpole.COM -
eric＠remailer.net -
Hal -
jamesd＠netcom.com -
Kipp E.B. Hickman -
kipp＠warp.mcom.com
-
Perry E. Metzger