Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Murray wrote: > It may be that the SSL underlying code is > perfect. But that the application is weak > because the implementor didn't understand > how to drive it; in which case, if he can > roll his own, he may end up with a more > secure overall package. I don't think this is likely to be true. In my experience, people who learn enough to design their own thing also learn enough to be able to do SSL properly.
> > SSLv2, which was also designed by an > > individual, also had major flaws. And that was the > > second cut! I haven't seen v1, maybe Eric can > > shed some light on how bad it was. > > [ Someone commented before that v1 was not deemed > serious (Marc A?) and v2 was the more acceptable > starting point (Weinsteins?). ] That's not true as far as I know. V1 and V2 were designed by the same guy (Kipp Hickman). V1 is actually very similar to V2, except that the integrity stuff is all screwed up. As far as I can tell, the fact of the matter is that Kipp didn't understand the security issues until Abadi and to some extent Schiffman sold them some clues. > > Peer review is not "design by comittie". > > Let me clarify. SSL - the protocol - was not > designed by committee, but, the size of the teams > involved in the crypto systems was in excess of > the people who were intimately familiar with the > protocol. For the most familiar example, browsing, > there were, it seems, many people involved in the > overall grafting of SSL into the original HTML/HTTP > system. As far as I know, that's not the case. The original Netscape team was very small and there really weren't any significant choices to be made. > > It is > > the way to get strong protocols. When I have to roll my > > own (usually because its working in a limited environment > > and I don't have a choice) > > I get it reviewed. The protocol designer usually misses > > something in his own protocol. > > Sure. If someone does roll their own, then they > should get it reviewed. That's not my experience. WEP and PPTP come to mind. > > > I'd say that conditions for Internet crypto system > > > success would include: > > > > 0. USE EXISTING SECURITY PRIMITIVES > > :-) > > I know this is the mantra of the field. > > Quesion is: which PRIMITIVES? > > 1. RSA? > 2. SSL, written from the RFC? > 3. OpenSSL, the toolkit? EKR's fine effort? > 4. RSADSI security consultants, selling you > theirs? > 5. ... I would say the highest level primitives you can get away with. > But, that assumes an awful lot. For a start, > that it exists. SSL is touted as the answer > to everything, but it seems to be a connection > oriented protocol, which would make it less > use for speech, media, mail, chat (?), by way > of example. SSL is quite fine for chat, actually. It's one of the major things that people use for IM. The issue with speech and media isn't connection-orientation but rather datagram versus stream data. > Then there is understanding, both of the > protocol, and the project's needs. I know > that when I'm in a big project and I come > across a complex new requirement, often, it > is an open question as to whether make or > buy is the appropriate choice. I do know > that 'make' will always teach me about the > subject, and eventually, it will teach me > which one to buy, or it will give me a > system tuned to my needs. The history of people who go this course suggests otherwise. They generally get lousy solutions. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/