Maybe It's Snake Oil All the Way Down

[Eric Rescorla]

Ian Grigg <iang at systemics.com> writes:
> Eric Murray wrote:
> It may be that the SSL underlying code is
> perfect.  But that the application is weak
> because the implementor didn't understand
> how to drive it;  in which case, if he can
> roll his own, he may end up with a more
> secure overall package.
I don't think this is likely to be true. In my experience,
people who learn enough to design their own thing also learn
enough to be able to do SSL properly.

> > SSLv2, which was also designed by an
> > individual, also had major flaws.  And that was the
> > second cut!  I haven't seen v1, maybe Eric can
> > shed some light on how bad it was.
> 
> [ Someone commented before that v1 was not deemed
> serious (Marc A?) and v2 was the more acceptable
> starting point (Weinsteins?). ]
That's not true as far as I know. V1 and V2 were designed
by the same guy (Kipp Hickman). V1 is actually very similar
to V2, except that the integrity stuff is all screwed up.
As far as I can tell, the fact of the matter is that Kipp 
didn't understand the security issues until Abadi and
to some extent Schiffman sold them some clues.

> > Peer review is not "design by comittie".
> 
> Let me clarify.  SSL - the protocol - was not
> designed by committee, but, the size of the teams
> involved in the crypto systems was in excess of
> the people who were intimately familiar with the
> protocol.  For the most familiar example, browsing,
> there were, it seems, many people involved in the
> overall grafting of SSL into the original HTML/HTTP
> system.
As far as I know, that's not the case. The original Netscape
team was very small and there really weren't any significant
choices to be made.

> > It is
> > the way to get strong protocols.  When I have to roll my
> > own (usually because its working in a limited environment
> > and I don't have a choice)
> > I get it reviewed.  The protocol designer usually misses
> > something in his own protocol.
> 
> Sure.  If someone does roll their own, then they
> should get it reviewed.
That's not my experience. WEP and PPTP come to mind.

> > > I'd say that conditions for Internet crypto system
> > > success would include:
> > 
> > 0. USE EXISTING SECURITY PRIMITIVES
> 
> :-)
> 
> I know this is the mantra of the field.
> 
> Quesion is:  which PRIMITIVES?
> 
> 1.  RSA?
> 2.  SSL, written from the RFC?
> 3.  OpenSSL, the toolkit?  EKR's fine effort?
> 4.  RSADSI security consultants, selling you
>     theirs?
> 5.  ...
I would say the highest level primitives you can get away with.

> But, that assumes an awful lot.  For a start,
> that it exists.  SSL is touted as the answer
> to everything, but it seems to be a connection
> oriented protocol, which would make it less
> use for speech, media, mail, chat (?), by way
> of example.
SSL is quite fine for chat, actually. It's one of the 
major things that people use for IM. The issue with
speech and media isn't connection-orientation but
rather datagram versus stream data.

> Then there is understanding, both of the
> protocol, and the project's needs.  I know
> that when I'm in a big project and I come
> across a complex new requirement, often, it
> is an open question as to whether make or
> buy is the appropriate choice.  I do know
> that 'make' will always teach me about the
> subject, and eventually, it will teach me
> which one to buy, or it will give me a
> system tuned to my needs.
The history of people who go this course suggests otherwise.
They generally get lousy solutions.

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com