Monoculture

[Thor Lancelot Simon]

On Thu, Oct 02, 2003 at 02:21:29PM +0100, Jill Ramonsky wrote:
> 
> Thanks everyone for the SSL encouragement. I'm going to have a quick 
> re-read of Eric's book over the weekend and then start thinking about 
> what sort of "easy to use" implementation I could do. I was thinking of 
> doing a C++ implentation with classes and templates and stuff. (By 
> contrast OpenSSL is a C implementation). Anyone got any thoughts on 

A C++ implementation will be much less useful to many potential users;
perhaps the most underserved set of potential SSL/TLS users is in the
embedded space, and they often can't afford to, or won't, carry a C++
runtime around with them.  We learned this lesson with FreSSH and
threads.

I would strongly recommend a C implementation with an optional C++
interface, if C++ is the way you want to go.

Also, I'd consider, for simplicity's sake, at least at first, implementing
*only* TLS, and *only* the required ciphers/MACs (actually, using others'
implementations of the ciphers/MACs, even the OpenSSL or cryptlib ones,
is probably not just acceptable but actually a _really good idea_.)  The
major problems with OpenSSL are, from my point of view, caused by severe
overengineering in the areas of:

1) Configuration
2) ASN.1/X.509 handling
3) Tightly-coupled support for the many diverse variants of SSL/TLS.

As far as what OpenSSL does, if you simply abandon outright any hope of
acting as a certificate authority, etc. you can punt a huge amount of
complexity; if you punt SSL, you'll lose quite a bit more.  As far as the
programming interface goes, I'd read Eric's book and then think hard about
what people actually use SSL/TLS for in the real world.  It's horrifying
to note that OpenSSL doesn't even have a published interface for a some of
these operations.  For example, there is no simple way to do the most
common certificate validation operation: take a certificate and an optional
chain, and check that the certificate is signed by an accepted root CA, or
that each certificate in the chain has the signing property and that the
chain reaches that CA -- which would be okay if OpenSSL did the validation
for you automatically, but it doesn't, really.

>From my point of view, a _very_ simple interface that:

1) Creates a socket-like connection object

2) Allows configuration of the expected identity of the party at the other
   end, and, optionally, parameters like acceptable cipher suite

3) Connects, returning error if the identity doesn't match.  It's
   probably a good idea to require the application to explicitly
   do another function call validating the connection if it decides to
   continue despite an identity mismatch; this will avoid a common,
   and dangerous, programmer errog.

4) Provides select/read operations thereafter.

Would serve the purposes of 90+% of client applications.  On the server
side, you want a bit more, and you may want a slightly finer-grained
extended interface for the client, but still, you can catch a _huge_
fraction of what people do now with only the interface listed above.

Thor

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