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]

Reply via email to