Adam Back <[EMAIL PROTECTED]> writes: > > 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).
On the other hand, without negotiation you can never fix problems later, like replacing a crypto algorithm that gets broken with one that is not compromised. However, you are correct that negotiation is an big weakness in many such protocols -- yet another reason for taking the utmost care in design and not to roll one's own lightly. > > (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. I think there is an excellent market for a variant on the protocol that uses SSH style keys, and for a library that implements that. Indeed, I would have immediate uses for such a library. However, the style of certificates isn't what is key to the security of the protocol's design. -- Perry E. Metzger [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
