LibTomNet [v0.01]

[Eric Murray]

On Tue, Jul 08, 2003 at 11:53:13AM -0700, Eric Rescorla wrote:
> Ian Grigg <iang at systemics.com> writes:
> 
> > It's not just you.  The field seems to be evenly
> > divided between those who view SSL as a mess, and
> > those who view it as the only sane choice because
> > so much attention has been put on it.
> I'm not sure why you think that these two views are
> inconsistent. Sure, SSL embodies lots of mistakes, and I'm hard on
> some of those in my book. However, my experience is that when people
> sit down and try to do a better job, they generally bungle it.  Tom's
> attempt is only the latest example.

Attempts to do new stuff should not be discouraged.
But like home-made ciphers, they should be viewed as interesting
learning exercises rather than serious secure protocols.


> > The main thing that reduces SSL's applicability to
> > real world problems come down to the assumption of
> > certificates as part and parcel of the security
> > model.
> This is just wrong. There are extensions to SSL to support Kerberos,
> SRP, and even primitive shared keys (see Peter Gutmann's latest draft
> on this topic).

Unauthenticated Diffie-Hellman has been in SSLv3 since the beginning.
Rejecting SSL because it "uses certifictes" is either a result
of ignorance of the spec or an excuse for re-inventing.

> > It's definately not just you - but one of the reasons
> > that it feels like that is that the SSL supporters
> > tend to protect their franchise very aggresively.
> It's not just SSL. I've beaten up on people who were trying to
> reinvent S/MIME in this very forum. It's just that people seem to try
> to reinvent SSL about 5 times more often than they try to reinvent
> anything else. My guess is that that's because the channel security
> problem *looks* so simple and so it seems like it should be easy to do
> something simpler and better than SSL.

If you are into wheels, it's more fun to (re-)invent the wheel the wheel
than it is to use the existing wheels laying about.  The posters here
are wheel geeks ("look, I can build a 12-spoke wheel!")  who are not
interested in the reliabilty of the bicycles that the wheels are used on.


> > Nonsense.  We aren't even up to being the C-team,
> > we don't make the team.  And we won't ever until
> > we cast off the shackles of rote acceptance, and
> > start challenging SSL on its inadequacies.

If you start with the same assumptions you will wind up
with something that looks very similar to SSL.  Once you have discovered
and addressed all the same holes and pitfalls that is.

While it's a fun learning exercise, it's not useful to the rest of
the world... SSL, because it has had more review than your protocol
will ever get, will be more secure.

The only way to end up with something significantly different
is to address a different set of requirements...  and more different
than "no certificates".

A good place to start is Eric's _SSL and TLS_ book.  
How can you make something better without understanding the mistakes
of the past?


Eric


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