Complexity of SSL (was Re: Closing on shared-key authentication)

> Tom Weinstein wrote:
> Michael Warner wrote:
> > I must take exception here - not with the advantages of making
> > security protocols easy to analyse, but with the implicit assertion
> > that SSL - and in particular the RSA based authentication/key exchange
> > - are easily analysed.   As presented in the current RFC, SSL v3 is
> > just about the most complex security protocol I have ever looked at.
> 
> Frankly, I'm baffled by this assertion.  Yes, SSL v3 is somewhat more
> complex than some other security protocols, but I don't think it is
> particularly resistant to analysis.  Bruce Schneier and David Wagner
> have performed an analysis of the protocol, and their paper contains no
> such complaints.

I haven't seen the paper analysing SSL - do you have a reference ?   I'd 
like to have a look.

I am sure some of the problems stem from the description in the Internet
Draft, which is not the most clear or concise.   It would be useful to see
a formal description and proof of the protocol - eg using BAN logic or 
similar.   The problems I have with the protocol are:

Challenges and identities are not signed explicitly, but rather they are 
mixed up with the hashes of other parameters.

Challenges and identities are not even together in the same message.

Identities are only in the protocol by virtue of the certificate.

"Indeterminacy" of what is being signed - the security of the protocol 
seems to depend on the certificate verify messages which sign the hash(es) 
of all previous messages in the protocol - which vary depending on whether
each party has a certificate etc.

Complexity of deriving the key from the "pre-master secret".   What is the 
point of this ?   It doesn't add to the randomness of the key.

Since you say that it is easily analysed, maybe you could summarise the 
protocol in a dozen lines, and describe which parameters are critical for
security, and how replay and man-in-the-middle attacks are thwarted ?

> There is an obvious man in the middle attack when the server has no
> certificate since client authentication is expressly forbidden in this
> case.

Where is this stated explicitly ?   If SSL is supposed to be a general 
protocol, why doesn't it support authenticated clients to unauthenticated 
servers ?

> > I would very much like to see SSL support different (and simpler)
> > authentication mechanisms.   Many have already been standardised -
> > X.509 being a notable example.
> 
> SSL does use X.509v3 certificates.  What kind of different
> authentication mechanisms are you talking about?

X.509 also defines an authentication exchange which can provide single
or mutual authentication.   1 2 or 3 message protocols are defined - 
depending on whether single or mutual authentication is needed, and whether
synchronised clocks are used.   The protocols have been analysed formally 
(in the process a weakness was found which has now been corrected).

Cheers,

Michael Warner
Telstra Research Labs

Received on Sunday, 13 October 1996 21:35:10 UTC