Don Davis <[EMAIL PROTECTED]> writes:

> EKR writes:
> > I'm trying to figure out why you want to invent a new authentication
> > protocol rather than just going back to the literature ...
> there's another rationale my clients often give for
> wanting a new security system, instead of the off-
> the-shelf standbys:  IPSec, SSL, Kerberos, and the
> XML security specs are seen as too heavyweight for
> some applications.  the developer doesn't want to
> shoehorn these systems' bulk and extra flexibility
> into their applications, because most applications
> don't need most of the flexibility offered by these
> systems.

I hear this a lot, but I think that Perry nailed it earlier. SSL, for
instance, is about as simple as we know how to make a protocol that
does what it does. The two things that are generally cited as being
sources of complexity are:

(1) Negotiation.
(2) Certificates.

Negotiation doesn't really add that much protocol complexity,
and certificates are kind of the price of admission if you want
third party authentication.

> some shops experiment with the idea of using only
> part of OpenSSL, but stripping unused stuff out of
> each new release of OpenSSL is a maintenance hassle.
But here's you're talking about something different, which is
OpenSSL. Most of the OpenSSL complexity isn't actually in 

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)


[Eric Rescorla                                   [EMAIL PROTECTED]

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

Reply via email to