Simple SSL/TLS - Some Questions

[Ian Grigg]

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 majordomo at metzdowd.com