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.


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

Reply via email to