Security APIs (was Open Source, was Simple SSL/TLS - Some Questions)

[Peter Gutmann]

Ben Laurie <ben at algroup.co.uk> writes:
>Jill Ramonsky wrote:
>> Too late. I've already started. Besides which, posts on this group
>> suggest that there is a demand for such a toolkit.
>
>I think there's demand in the sense that there's demand for free lunches.

Yup.  And the real measure of demand for something isn't how many people line
up to eat the lunch you've made but how many volunteer to help you prepare it.

>People would like the inherent complexity to go away, because they can see
>that there's a way simpler API that addresses _their_ problem, but I fear
>that a good deal of the complexity in TLS is not removable, so all that will
>happen is that the API will be unsuitable for almost everyone else's problem
>- or it'll still be complex.

That's the exact problem with most security functionality.  Look at the NT ACL
API for example.  Microsoft have been rewriting that in every OS release in an
attempt to make it more accessible, but have mostly just ended up with a pile
of equally awkward ways of doing things.  This isn't because of bad design,
but because there's no easy way to handle this kind of complex security
functionality in a manner that works for all people.  When working with ACLs I
actually prefer the original NT 3.1 API to the awful sendmail.cf-style ACL
minilanguage they invented for NT 4.0, because although the original was
awkward to use, you at least knew what you were getting.  In more recent
attempts to make it usable they've added a pile of DoSomeHighlySpecificThing-
ToThisParticularFileInThisParticularContext() type functions, but unless you
want to perform the one or two predefined operations they give you, you still
need to use one of the more complex APIs.

Coming a bit closer to home, let's look at what's necessary for a TLS API.
I'm going to use the cryptlib API, both because that's what I'm most familiar
with and because the design is strongly driven by user requirements, so I can
say with a reasonable level of confidence that the stuff I mention below is
based on what users actually want and use.  At the simplest level, you can
establish a connection with three calls (taken straight from p.87 of the
manual in this case):

  create session;
  add server name/URL;
  activate session;

You could actually condense this down to a single function:

  session = open_session( server_name );

except that almost no-one would ever use this for the same reason that almost
no-one would ever use the three-simple-function-call version above: It does no
checking of anything, and doesn't handle most of the special cases that users
want.

First of all, you need to authenticate the connection.  Typically this is done
via certs, so you need to fetch the server cert, check the signature, check
the server URL against the one in the cert, perhaps check its validity/
revocation status, check the issuing cert, the whole X.509 circus.  Since
everyone wants different levels and types of checking, your API needs to be
able to handle all the different cases.  Then some poor misguided souls will
inevitably want to use client certs (typically because they read about them in
some whitepaper and have no idea how much pain they're in for) so you have to
support those as well.  Of course the server side needs to check these certs,
so you need the whole PKI mess on the server as well.

Next, no-one can agree on how to handle the network connection.  Some want you
to handle it for them, some want to handle it themselves, some want to set it
up themselves but pass it on to you (e.g. STARTTLS/STLS use), and some want
one of the above but want to handle network events themselves.  Then there are
variants of the above: Of the DIY-connection crowd, some will handle network
events via select() or poll() (or (shudder) WSAAsyncSelect(), which has some
really cute features of its own), but others are running odd embedded OSes
where the event-handling functionality is done by various event_wait() style
functions that act as general-purpose event demultiplexers and require all
sorts of special-case handling.

Now I haven't even got to any of the real complexity, just the basic
establish-a-link bit, and already you're starting to get an awfully complex
API.  It's not just a case of designing an interface that keeps things as
simple as possible for those who want a simple API while still allowing
everyone else to apply their preferred network interfacing mechanism, you then
need to actually code and test all of the various ways of applying the
networking.

Let's skip this low-level networking stuff for now and look at what else is
needed.  Well, since you're more or less requiremed to use certs if you use
SSL (TLS-SRP and TLS-sharedkeys will fix this in the future), you need to be
able to create the things, which means that you also need to handle key
generation and storage.  Some people will want to use smart cards (storage)
and crypto accelerators (server-side) for this, so you need a crypto device
interface.  Then if you're not using self-signed certs (some people want them
from a CA) you need to handle CA cert enrolment and issue.  OTOH if the people
want to issue their own certs, you need CA functionality, and if you do that
in anything more complex than a simple ad hoc manner you need a whole pile of
awkward PKI protocols (CMP, SCEP, OCSP, etc etc) to handle all of that.

All of a sudden your original elegant Venus de Milo is looking more like Durga
(Hindu goddess) with an assortment of arms holding a trident, a lotus, an
elephant goad, a can-opener, an annoyed-looking wombat, and a small bent thing
with a knob at one end, riding on a tiger, and with an entire religion devoted
to interpreting the different nuances and mystic symbolism (hmm, that sounds
like OpenSSL :-).

So it's not just a case of saying "I'm going to create something with a simple
API", because you end up either creating a simple, straightforward, do-
exactly-what-I-want implementation that no-one else can use because it doesn't
do what *they* want, or if it does become popular with users you'll be forced
to add a huge pile of functionality to cater for different user requirements.
Getting back to cryptlib as an example, if you only require very minimal,
fixed functionality, it'll run in very little (the smallest implementation I'm
aware of consists of an ASIC, an external RAM chip, and an Ethernet socket,
running an SSL web server and control software, there's also one running in a
USB token but I think that has a bit more hardware to play with), but that's a
do-exactly-what-I-want application that suits the needs of exactly one user.
For general-purpose use, you need a huge pile of support functionality for
which, even if an individual user only requires 10% or 20% of it, the overall
user community all require different 10-20% bits, so that in the end you have
to support the whole lot to keep all the users happy.

Jill Ramonsky <Jill.Ramonsky at aculab.com> writes:

>And if it turns out that I'm wrong, and those who encouraged me are also
>wrong, and there is no big demand for "Simple-to-use SSL/TLS" after all, then
>I don't care - because _I_ want to use it, and that, to me, is the most
>important demand of all.

I guess that's always a good reason for writing something, but for any project
of this size you'll either need extreme amounts of perseverance or an active
user community to encourage you to keep going, and (more important from a
security perspective) to stress-test the code in unusual applications to allow
you to identify and fix any problems that might arise.  My original message
wasn't to try to discourage you from writing code, but pointing out that
you're competing in an extremely crowded market, which makes it somewhat
unlikely that the latter will occur, so that you're counting entirely on the
former (your own perseverance) to keep things going.  This probably isn't the
most optimal way to motivate a large coding project.

Peter.

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