eric wrote:
> The way I see it, there are basically four options:
> (1) Use OpenSSL (or whatever) as-is.
> (2) Strip down your toolkit but keep using SSL.
> (3) Write your own toolkit that implements a
>     stripped down subset of SSL (e.g. self-signed
>     certs or anonymous DH).
> (4) Design your own protocol and then implement it.
> Since SSL without certificates is about as simple
> as a stream security protocol can be, I don't see
> that (4) holds much of an advantage over (3)

i agree, except that simplifying the SSL protocol
will be a daunting task for a non-specialist.  when
a developer is faced with reading & understanding
the intricacy of the SSL spec, he'll naturally be
tempted to start over.  this doesn't exculpate the
developer for biting off more than he could chew,
but it's unfair to claim that his only motivation
was NIH or some other sheer stupidity.

btw, i also agree that when a developer decides to
design a new protocol, he should study the literature
about the design & analysis of such protocols.  but
at the same time, we should recognize that there's a
wake-up call for us in these recurrent requests for
our review of seemingly-superfluous, obviously-broken
new protocols.  such developers evidently want and
need a fifth option, something like:

   (5) use SSSL: a truly lightweight variant of
       SSL, well-analyzed and fully standardized,
       which trades away flexibility in favor of
       small code size & ease of configuration.

arguably, this is as much an opportunity as a wake-up

                                - don davis


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to