[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MD5 versus SHA -Reply

I second Frank's remarks.

1) defaults are intended to provide a least common denominator.  They may not
be as fast or even as secure as later options. 

2) design the protocol for extensibility so future extensions are easy to adopt.  In this
case, with algorithm IDs to describe interworking solutions.

3) don't let the proposal go forward without some required, common, even if sub-optimal
required algorithms (two, really - a null facility meaning we're not doing security on this
session, and one of the algorithms under discussion. 

4) for the default algorithm, select on the basis of strength rather than speed.  Other
algorithms will provide speed.  We're sunk if the mandated algorithm lacks "adequate"
strength for some measure of adequacy which may be obsoleted at sometime in the future.

All of this is, of course, modulo import/export and trans-boarder data flow issues.

I presume that since MD5 transformations are not reversable that the thrust of the current
discussion has to do with data integrity checks, and tying that to the identity of the remote
party via a negotiated symetrical session key.  And that there is not a notion of *mandating*
support for data stream encryption in IPv6 compliant implementations.  Right?

Ed Reed
Novell, Inc.

>>> Frank Kastenholz <kasten@ftp.com> 03/29/95 07:31am >>>
There is a logical flaw with not specifying a 'default' algorithm.
If an algorithm is the "default algorithm" then one can assume that that algorithm is
common to all implementations. Every node and implementation can be assured that every
other node which does security will do the default.

Now, consider what happens if there is no default. I may implement algorithms B and C and
you might implement algorithm D. Each of these may be stronger or better (in whatever
sense) than algorithm A. But we will not be able to communicate in a secure manner since
we do not do the same algorithms. We each will say "We are better than A" but we will not
be able to communicate securely. Is this good?

A common, default, widely-fielded, algorithm is required. 

You say that speed is important. It is. But I urge that we specify an algorithm and field it.
Soon. The internet has needed, and lacked, a security scheme for many years. In part it's
because we've always been searching for a 'better' system -- faster, cheaper, stronger, etc.
We've put off fielding what we have because tomorrow we might have something better. We
might get something better tomorrow, but what we can field today is infinitely better than
what we are using today.


 > I'd like to suggest something a bit stronger.
 > 
 > While I agree that consensus on strength is important,
 > I would like to argue that consensus on speed is equally important.
 > 
 > If we don't have something that breaks 100 Mbps on a Sparc 10/51
 > in software (ballpark...), I propose that we do not specify
 > a default authentication algorithm at all at this time.
 > 
 > *********************************
 > 
 > If not specifying a default will be detrimental to the acceptance
 > and use of the option, I see this as a challenge to find an
 > algorithm that is fast; not an excuse to use one that is not.
 > 
 > *********************************
 > 
 > I'm still seeking one, if anyone has any ideas.
 > 
 > 
 > Joe
 > 


--
Frank Kastenholz    "The dogmas of the quiet past are inadequate to the stormy
                     present... As our case is new, so we must think anew, and
                     act anew" - A. Lincoln