[14365] in cryptography@c2.net mail archive
Re: Monoculture
daemon@ATHENA.MIT.EDU (Eric Rescorla)
Wed Oct 1 14:12:59 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: Don Davis <don@mit.edu>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: 01 Oct 2003 08:53:39 -0700
In-Reply-To: <a05100309bba098467c15@[206.15.139.111]>
Don Davis <don@mit.edu> 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
SSL.
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)
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
