Jill Ramonsky wrote: > > Having been greatly encouraged by people on this list to go ahead with a > new SSL implementation, it looks like I am going to go for it, but I'd > kinda like to not make any enemies in the process so I'll try to keep > this list up to date with progress and decisions and stuff ... and I > will ask a lot of questions.
Don't worry about making enemies, they'll worry about it for you :-) > It's worth summing up the design goals here, so nobody gets confused. > Trouble is, I haven't figured out what they should all be. The main > point of confusion/contention right now seem to be (1) should it be in C > or C++?, C. And write C++ wrappers or let someone else do it. (IMHO. I don't write much C++ but it seems to be basically dangerous and difficult to get right. Also, you already have enough on your plate in securely handling C, without having to worry about the built in insecurities of C++ :-) > (2) should it support SSL or TLS or both? Just TLS, and only the compulsory parts. Leave in hooks for other parts right now. Also, ditch the Anon-DH mode, and stick to the cert model. Again, IMHO. Your market will be developers who want a simple secure channel product. Market in general will not be people who already have to meet SSL as a spec, those people will go with OpenSSL. You want the green field developers, and there is no reason to offer them old stuff. > Regarding the choice of language, I think I would want this library (or > toolkit, or whatever) to be somehow different from OpenSSL - otherwise > what's the point? I mean ... this may be a dumb question, but ... if > people want C, can they not use the existing OpenSSL? Or is it simply > that OpenSSL is too complicated to use, so a "simpler than OpenSSL" C > version is required. What I mean is, I don't want to duplicate effort. > That seems dumb. OpenSSL is thought to be complex, less well documented, hard to use. I've not "used" it, but I've hacked it a couple of times, and that's how I remember it. You sort of have to be a C programmer so you can muck in and figure out what it is doing. Also, OpenSSL provides everything. But you have to know how to configure everything up. So you have to understand the choices placed in front of you, or blindly follow the lead of various examples. So, an alternate approach is to set up one way of doing everything, to give you one rather good, but not perfect, connection product. It may very well have improved an awful lot since I've looked, who knows? But, reports keep coming in that it is too hard to get into... > .... My inclination is still to go with C++, and figure out > a way of turning it into C later if necessary ... but if majority > opinion says otherwise I'll reconsider. Go with your gut feel. Don't listen to the experts, you'll never get a consistent viewpoint, and even the ones that disagree will be wrong :-) > Now - SSL or TLS - .... If > you want to implement only TLS (for example, in a closed private network > where all parties are known to be using the same version of the same > protocol), why should you have to lug around SSL as well? I suppose I > /want/ the solution to be "allow the toolkit to generate either > SSL-only, or TLS-only, or SSL+TLS" ... but what I'm not sure about is, > is the "TLS-only" option forbidden by the standard? My advice: if the standard gets in your way, ignore it. All standards are camels, and your job is to ride beasts of burden, not the other way around. Deliver product, and don't let a bunch of horse designers push you around. Create a single security product that talks just pure TLS. The latest and greatest. You will have enough to worry about keeping track of future changes, let alone dealing with ancient history. Bear in mind that you are looking at a year-long project here. There is a reason why OpenSSL is the choice... because it is already written. > And now some questions about SSL/TLS itself.... I'll think more on those, or quietly slink away without appearing more dumb than normal. All the above is IMHO, so please try hard to ignore it! iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
