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). > (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. Adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
