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. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]