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