Ben Laurie <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
