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

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

From: Tom Weinstein <tomw@netscape.com>
Date: Thu, 09 May 1996 00:29:07 -0700
Message-Id: <31919EC3.237C@netscape.com>
To: Bennet Yee <bsy@cs.ucsd.edu>
Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
Bennet Yee wrote:
> 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"
> construction?

I think there are two different philosophies about how to react to a
failure of one of the MAC functions.  The SSL 3.0 philosophy seeks to
design a redundant system that can withstand a single failure but then
requires a patch to regain the redundancy.  The STLP strawman philosophy
allows a failure to compromise the system, but allows it to be fixed by
a simple configuration change on the part of either party.  Both
philosophies have merit.

Incidentally, the handshake hashes in the final version of the SSL spec are
computed as (MD5(MD5()) + SHA(SHA())), not (MD5(SHA()) + SHA(MD5())) as in
early versions.  We felt that not alternating algorithms provided at least
the same level of collision intractability without the somewhat dubious
mixing of algorithms that you seem to be concerned about.  The assumption
then is that the algorithms are sufficiently unrelated so as to provide
uncorrelated outputs.

>>> 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.

Yes, I'd agree that MD5 should certainly not be used for the STLP response
message.  It seems to depend fairly strongly on the collision
intractability of the hash function.  I also agree with you that everyone
should move away from MD5.  I expect that MD5 will be in very bad shape
in the not too distant future.

>> 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.

Absolutely.  But the only way to defeat the roll-back attack is to have
every installed product that uses the insecure algorithm configure it off.
Personally, I worry that as more and more naive users begin to rely on
cryptographic software, it will become harder for us to do that.

-- 
One tag to rule them all, One tag to find them; One tag | Tom Weinstein
to bring them all, and in the source tree bind them.    | tomw@netscape.com
Received on Thursday, 9 May 1996 03:29:56 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:48 EDT