Simple SSL/TLS - Some Questions

[Jill Ramonsky]

Hi. This is just a quick note to say that over the weekend I've done a 
lot of thinking about coding, and even some /actual/ coding, that I've 
re-read parts of Eric's book in somewhat more detail than I read it last 
time, and I've read all the various posts on the subject of "simple 
SSL". And at the end of all this study, I have finally decided exactly 
what I want/propose to do . I guess the point of this email is to tell 
you the plan, and to explain the reasons for my choices. There are also 
four more questions at the end,  so if you can't be bothered to read 
this long email, please do skip to the end and consider the questions.

First, the primary design goal is "simple to use". This is not the same 
thing as "doesn't do much". As an implementer, I can make the toolkit as 
powerful as I want (and it will be open source, after a time, so others 
will be able to add to it and make it more powerful still). Adding power 
only makes the implementation harder to /write/. However, if well 
designed, it should not make it harder to /use/. Harder to write is my 
problem ... but I like a challenge!

Second design goal is "lightweight". This means that it must be possible 
for application programmers to use the toolkit to build minimalist 
applications. This means that part of the toolkit must be a 
statically-linked library consisting of many very small object modules, 
making it possible to link in only what you need, and no more. That 
said, if the toolkit is powerful, one could also use it to build 
"heavyweight" applications also. I don't see that as a problem, or even 
as a violation of the design goal. In fact, it actually seems to me to 
be something of an advantage that you could do both.

First design choice: SSL or TLS or both? I think this is covered by the 
paragraph above. If the toolkit lets you create TLS-only products, a lot 
of people will be happy (including me). If the toolkit /also/ lets you 
build SSL+TLS applications then a lot of /other/ people will be happy. 
Seems to me that so long as I am clear about the distinction between 
"what's in the toolkit" and "what's in a application /built/ with the 
toolkit" then a lot of design choice problems just disappear. (Or at 
least, become the application designer's problem).

Second design choice: C or C++ or something else? There was a lot of 
support on this list for both C and C++, and various "something else"s 
were also suggested, but with less votes. Many people suggested /both/ C 
and C++. Some said "write in C and then do a C++ wrapper". Others said 
"write in C++ and then do a C wrapper". The "embedded market" got 
several mentions, and for these guys it's clearly desirable to have a C 
version. Other factors to consider are my own expertise (I've never 
written anything in Ruby or Python before, so this would not be a good 
project to use as first attempt) and my own enjoyment. This is selfish, 
yes, but someone said this would end up being a year-long project, so 
I'd like it to end up firing my enthusiasm and imagination. More gets 
done that way, and faster. So here's the decision - the prototype will 
be in C++ ... /but/ ... I do know enough about how C++ compilers work 
behind the scenes, and I'm confident that I will be able to later port 
it to C, even /with/ features such as abstract virtual base classes, 
templates, exception handling, RTTI and so on. So what we'll end up with 
is both a C++ version and a C version, with the C++ version coming 
first. [It may even be possible to shortcut the port, for example by 
finding a C++ to C compiler, or by releasing an OS-specific binary with 
C wrappers]. And it seems to me that another big plus in doing a C++ 
version is that one does not already exist, and perhaps one should. 
Another big pro in favor of C++ is the existence of the crypto++ project 
(thanks for pointing that out to me, guys). This provides a lot of 
crypto primatives, which a TLS toolkit could put to good use.

Some people said that it was easier to code in C than in C++. I don't 
think that's true. I've been coding in C since it was invented. 
Likewise, I've been coding in C++ since /that/ was invented. In my 
opinion, bugs are easier to find and fix in C++ than they are in C, with 
most of the serious ones being detectable at compile time in C++, but 
only at run time in C. With that in mind, I believe I could do a safer 
implementation in C++ than I could in C. I also consider the fact that 
the reason C++ was invented was to help manage complexity, and let's 
face it, this project does involve complexity. Keeping it all 
object-oriented gives me nice little isolated, easily debuggable objects.

It was pointed out that C++ (as opposed to Java, etc.) does allow 
pointers, and hence does allow memory errors such as buffer overruns. 
That's true, but I tend to encapsulate my raw C++ pointers inside smart 
pointer objects which don't allow such errors. (These are already part 
of my existing codebase. They'll go open-source along with the rest of 
it). I believe I can minimise this danger.

Eric raised some points which I should address. First, he asked me "You 
have read the RFC, right?". Well I guess I should be honest here and say 
no, I hadn't done that yet. Maybe that's where I went wrong, and would 
have asked fewer dumb questions if I had. But rest assured everyone, I 
will digest it thoroughly before trying to implement it! He also asked 
"I'm trying to figure out why you care about this. The defined 
algorithms are good enough for almost all purposes.", and "Don't you 
want to be able to communicate with standard TLS implementations? If so, 
the kind of stuff you seem to want to do will in often break that.". To 
answer the first question, I have to state my absolute and sincere 
belief that if Alice, Bob, Carol, Dave, etc.., wish to communicate with 
each other privately, then it their business AND NO-ONE ELSE'S what 
choice of algorithm(s) they use, etc.. This leads inevitably to the 
conclusion that if a standards body forbids this, then the standards 
body will have to be circumvented. This of course leads to the second 
question, ("Don't you want to be able to communicate with standard TLS 
implementations?"). The answer is obvious. /Of course/ one should be 
able to communicate with standard TLS implementations, otherwise the 
toolkit would be worthless. And of course, communicating with other 
implementations /does /mean strictly obeying all the standards. These 
two positions are not, however, mutally exclusive, because what I am 
putting together is a /toolkit/, not an /application/. Application 
programmers will be able to use the toolkit to build standards-compliant 
applications if they want that, or anarchistic applications if they want 
that. (Of course, anarchistic applications will not interoperate with 
the rest of the world, but that's the price you pay for choosing that 
option, and it's what I mean by the phrase "private use by mutually 
consenting parties").

And now ... SOME MORE QUESTIONS. (You're gonna love this).

(1) THE LICENCE

I confess ignorance in matters concerning licensing. The basic rules 
which I want, and which I believe are appropriate are:
(i) Anyone can use it, royalty free. Even commercial applications.
(ii) Anyone can get the source code, and should be able to compile it to 
executable from this.
(iii) Copyright notices must be distributed along with the toolkit.
(iv) Anyone can modify the code (this is important for fixing bugs and 
adding new features) and redistribute the modified version. (Not sure 
what happens to the copyright notices if this happens though).

(2) THE NAME

Everything needs a name. I've come up with a few possibilities. I'd bet 
good money that people here could come up with a few more. Some 
suggestions are:
TLS++ (I like this one)
SimpleTLS (obvious, but not too bad)
EasyTLS (actually I'm not too keen on this - it sounds /too/ simple to 
be credible)
GnuTLS (obviously only suitable if it ends up with a Gnu license)
Pretty Good TLS (I stole the idea from PGP obviously, but if this is to 
be "SSL for the masses" then it's not entirely inappropriate)
...
Anyway, all suggestions welcome.

(3) MULTIPLY SIGNED CERTIFICATES

A technical question now. (I did look at RFC2246 before asking this, but 
didn't find the answer there). In GPG / PGP, one can have multiply 
signed certificates. It's not called a "certificate" in GPG, it's called 
a signed key, but the priniciple is the same. Alice can get her key 
signed by both Carol and Dave, which has the intended meaning that both 
Carol and Dave vouch for the authenticity of Alice's key. Thus, if Bob 
wishes to send to Alice, he can do so provided he trusts /either/ Carol 
/or/ Dave.

Can you do this with X.509 certificates? I know it would be hideously 
unusual (not to mention expensive) to get a single certificate signed by 
both Verisign and Thwarte, but can it be done? Is it possible? Is it 
allowed?

(4) MULTI-THREADING

Procedural languages like C tend to go for state-machine-like 
architectures. Object oriented languages like Java tend to go for 
multithreading. Both are conceptually solutions to the same problem, but 
arise from different paradigms. C++, being somewhere in the middle, 
hasn't really made up its mind which way to go. Multithreading is not 
built into C++ any more than it is built into C, but the OS usually 
provides multithreading anyway, so in object-oriented C++ you'd tend to 
go for multithreading (which, I have to say, is /considerably/ easier to 
understand and debug than the state-machine paradigm). My question is, 
how much of a problem is this for the embedded market?

I happen to know that it's pretty easy to put *cooperative* 
multithreading into an embedded application, providing you're willing to 
write a bit of assembler. (I've done it myself). But *pre-emptive* 
multithreading is much harder to implement (and more likely to incur 
synchronisation bugs). I can certainly write multithreaded routines 
which don't rely on pre-empting, so that should make it easy, but 
obviously I'm not going to write assembler thread-switching code for 
every processor under the sun.

Thoughts and opinions would be welcome.

Jill


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com