W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Re: [Fwd: HMAC-MD5: to be or not to be?]

From: Bennet Yee <bsy@cs.ucsd.edu>
Date: Wed, 08 May 1996 23:27:48 -0700
Message-Id: <199605090627.XAA06877@work.ucsd.edu>
To: Tom Weinstein <tomw@netscape.com>, "'ietf-tls@w3.org'" <ietf-tls@w3.org>

In message <31914761.3F54@netscape.com>, Tom Weinstein writes:
> Dan Simon wrote:
> > [ ... ]
> > In that case, though, either MD5 should be removed from the "handshake
> > hash" (or replaced with another, non-broken hash function), since it
> > is used there without a key prefix to the input, or the "handshake
> > hash" should be restructured as an HMAC-style MAC.  (I'll make another
> > pitch here for not explicitly specifying the hash function or
> > functions used in the "handshake hash"; if this news about MD5 had
> > come out a year later, then the body of the spec itself would have had
> > to be revised, instead of just the list of valid hash functions).
> I don't believe this is true.  The way the handshake hashes are used in
> SSL 3.0 requires that a collision exist in both MD5 and SHA1 for the same
> pair of message streams.  To construct such a collision is currently
> computationally infeasible.  Negotiating the function(s) to be used in the
> handshake hashes allows a roll-back attack if any of the possible hash
> functions are compromised.  

The point is that the hash has to be "possible".  The idea with having
the functions separately negotiable is that the user is involved when
researchers announce new techniques to void the collision
intractibility assumption -- GUI or user-accessible configuration
files must be provided so that the user can easily turn off a broken
hash.  Alternatively, an automated revocation-list style of operation
is possible.  This, I believe, is the approach that Dan Simon is
advocating.  I think that this is a reasonable approach.

The SSLv3 approach seems to be to try to use multiple hashes to build
up a more-collision-intractible hash for the handshake hashes.  On the
face of it, this looks pretty reasonable too and avoids issues with
user confusion / service calls.  There is a "however" side to this: I
don't believe that anybody has calculated/proven the actual security
of the alternating SHA/MD5 constructions (relative to the security of
the base hash functions) used for generating key material.  If the
construction were really sound, maybe it'll be of interest to
researchers since it'd be a general way to build
more-collision-intractible functions from less-so ones.  Furthermore,
if there is a real need to build stronger hashes out of possibly weak
ones, then why are we limiting ourselves to just MD5 and SHA?  To just
one application of this collision-intractibility "strengthening"

> > after all, the new break affects not only the MAC method, but also
> > (hash-and-)signature-based authentication, where no secret MAC key can
> > be relied upon to make collision-finding harder.
> What are you talking about?  The MAC is SSL 3.0 is keyed and relies
> primarily on the secrecy of the key, not the collision intractability
> of the underlying hash function.  Both places where signatures are used
> rely on both MD5 and SHA (except for DSA signing).  What kind of attack
> do you think a hash collision could allow on the signed messages?

In STLP there are options to use a signature key to authenticate; see
the response message, 5.2.5, in the STLP draft.  Like SSLv2's client
authentication, but more symmetric.  Furthermore, the world is larger
than PCT/SSL/STLP/TLA-of-the-day.  The PKCS standards, for example.

> As I already stated, I believe that allowing negotiation of the algorithm
> used for computing the handshake hashes allows a roll-back attack.  The
> use of a single algorithm is also weaker than the paired algorithms
> currently used.

A roll-back attack is possible only if the hash function remains
enabled.  Whether a revocation style of cryptographic primitive
management to automate things is doable or manual, user intervention
is used, it -is- possible to disable the use of some
crypto-primitives.  Completely disabling a (newly found to be) weak
crypto-primitive is preferable to leaving it in place.


Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114
Received on Thursday, 9 May 1996 02:27:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:11 UTC