Simple SSL/TLS - Some Questions

[Jill Ramonsky]

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.

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++?, (2) should it support SSL or TLS or both?

There are plenty of things I am really sure about, however. The two main 
design goals people seem to want are (1) lightweight, and (2) easy to 
use. (Plus the "obvious" goals of (3) it actually /will/ implement 
SSL/TLS and not something else, and (4) it shouldn't be full of bugs. I 
figure those go without saying).

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.

C++ has many advantages, which include SECURITY advantages. Proper use 
of constructors, destructors, exceptions, std::strings, std::vectors, 
smart pointers, and so on can eliminate memory leaks, dangling pointers, 
buffer overruns, and just about everything else than can bring a good 
toolkit down. I already have a very nice, working, C++ secure 
big-integer library [here's one I wrote earlier]. By "secure" in this 
context, I mean that all big-integers get zeroed on deletion, so no 
crypto keys are ever left lying around in memory. Sure, these sort of 
things are all also possible in C, but it's so much more work to be 
/sure/ that every error condition is dealt with. Is embedded C++ 
non-existant then? I'm pretty sure it's possible to compile C++ to C 
(instead of to assembler) so a C++ to C wrapper can't be that difficult. 
(By contrast, a C to C++ wrapper would be easier, but the toolkit would 
have more bugs!) 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.

Now - SSL or TLS - this confuses me. From what I've read in Eric's book, 
SSL version 3.0 or below is called SSL, wheras SSL version 3.1 or above 
is called TLS. Have I misunderstood that? In any case, I note the bit in 
Eric's book (p73 in my edition) where it says "In general, it is 
expected that an implementation speaks all lesser versions" ... even if 
lesser versions become known to be insecure. I'm not sure I like this - 
and in any case, it goes against the design goal of "lightweight". 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?

And now some questions about SSL/TLS itself....

THE HANDSHAKE PHASE

The assumption in Eric's book, roughly translated into Alice and Bob 
scenarios, goes something like this: Bob (client) says hello to Alice 
(server). Alice sends Bob her certificate (which is basically a copy of 
her public key, signed by a third party, Carol). Bob validates Alice's 
key (which is only possible if he already has a copy of Carol's public 
key), and then uses Bob's (now validated) public key to start sending 
encrypted messages. (There's more, but that's the important part).

Now, this scenario is all very well for banks and big businesses, but I 
guess I want to do "SSL for the rest of us". You see, the above scenario 
contains a couple of assumptions. It assumes (1) that Bob does not 
already have Alice's key - otherwise why would she need to send it? It 
further assumes (2) that Bob /does/ have Carol's key, /and that he 
trusts Carol/. Okay, fine, but what if these assumptions aren't met? I 
mean, let's assume that Bob already has Alice's key. (Let's say for sake 
of argument that she gave it to him personally). Now this means we can 
save on bandwidth by not having to transmit Alice's cert ... but already 
there are two problems: (1) would it be a violation of the protocol to 
omit the cert?, and (2) without the cert, we would need some /other/ 
kind of message with which to replace it - one which says, simply, "Hi, 
this is Alice, use the copy of my key which you already have". So 
already I have questions - how free am I to allow variations in the 
handshake?

THE CIPHER SUITE

The list on page 74 of Eric's book looks a little limiting to me - not 
merely because the list is too short, but also because it's very design 
is wrong (in lumping all of the encryption ciphers together into a 
single 16-bit value with no internal structure). What if Alice would 
like to use, say, some elliptic curve function as her asymmetric 
algorithm?, or CAST-5 as her symmetric algorithm?, or SHA-256 as her 
hash function? We could maybe fix this up by adding more entries to the 
list, but it's a global list, so who has the authority to add entries to 
it? I believe that Alice and Bob should be able to communicate with 
whatever ciphers they wish, and should not need the permission of any 
global authority to do this. Are there any values in the range (0x0000 
to 0xFFFF) which are reserved for private use between consenting parties?

It is even possible for Alice and Bob to use a proprietry cipher. For 
example, what if the chosen encryption algorithm is "one-time-pad", 
using a block of bits communicated out of band (e.g. via so-called 
quantum cryptography, or that hard-drive alternative discussed in 
another thread). How can this be communicated in the CipherSuite field? 
I would like to believe there is a way of doing this ... but if not, I'd 
like to know that too, so I can find a neat way of extending the 
protocol to /make/ it possible.

THE COMPRESSION METHOD

Exactly the same question. Alice and Bob are consenting adults, and they 
want to use the BZIP compression algorithm. I'm not going to tell them 
they can't. (I suspect though that the answer to the previous query will 
also answer this one).

THE CERTIFICATE

Can Alice and Bob each create their own certificates? With (for example) 
Alice's key signed by Bob, and Bob's key signed by Alice, as is often 
done in GPG? Who counts as the "Issuer" in this case? How can Alice (or 
a piece of software working on Alice's behalf) construct an X.500 
Distinguished Name to describe herself /and be absolutely sure that it 
is globally unique/? On page 12 of Eric's book it explains that a DN is 
a sequence of RDNs, each of which only needs to be locally unique, so 
the whole sequence becomes globally unique. That's all very well, but 
it's still a global namespace overall, so who controls it? Let me be 
clear that Alice and Bob have no intention to give even a single penny 
to Verisign or any other entity, just so that they can talk to each 
other in private.

FINISHED

Well, that's enough questions for now. Hopefully someone can answer some 
of them. Encouragement is great, and I appreciate it, but practical 
answers to the above would be even better.

Cheers,
Jill



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