Adam Back <[EMAIL PROTECTED]> writes:

> On Wed, Oct 01, 2003 at 08:53:39AM -0700, Eric Rescorla wrote:
> > > there's another rationale my clients often give for
> > > wanting a new security system [existing protcools] too heavyweight for
> > > some applications.
> > 
> > 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.
> >
> > Negotiation doesn't really add that much protocol complexity,
> eh well _now_ we can say that negotiation isn't a problem, but I don't
> think we can say it doesn't add complexity: but in the process of
> getting to SSLv3 we had un-MACed and hence MITM tamperable
> ciphersuites preferences (v1), and then version roll-back attack (v2).
Right, but that's a DESIGN cost that we've already paid. 
It doesn't add significant implementation cost. As in check
out any SSL implementation.

> > (2) Certificates.
> >
> > and certificates are kind of the price of admission if you want
> > third party authentication.
> Maybe but X.509 certificates, ASN.1 and X.500 naming, ASN.1 string
> types ambiguities inherited from PKIX specs are hardly what one could
> reasonably calls simple.  There was no reason SSL couldn't have used
> for example SSH key formats or something that is simple.  If one reads
> the SSL rfcs it's relatively clear what the formats are the state
> stuff is a little funky, but ok, and then there's a big call out to a
> for-pay ITU standard which references half a dozen other for-pay ITU
> standards.  Hardly compatible with IETF doctrines on open standards
> you would think (though this is a side-track).
> > Since SSL without certificates is about as simple as a stream
> > security protocol can be
> I don't think I agree with this assertion.  It may be relatively
> simple if you want X.509 compatibility, and if you want ability to
> negotiate ciphers.

I said WITHOUT certificates.

Take your SSL implementation and code it up to use anonymous
DH only. There's not a lot of complexity to remove at that point.


[Eric Rescorla                                   [EMAIL PROTECTED]

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

Reply via email to