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

RE: Merged Transport Layer Protocol Development

From: Dan Simon <dansimon@microsoft.com>
Date: Mon, 29 Apr 1996 10:42:43 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-92-MSG-960429174243Z-36975@tide19.microsoft.com>
To: "'Tom Weinstein'" <tomw@netscape.com>
Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>
>From: 	Tom Weinstein[SMTP:tomw@netscape.com]
>Dan Simon wrote:
>> Interestingly enough, the authors of SSL seem to disagree; the most
>> sensitive MAC in their entire protocol (the "handshake hash") is
>> computed with the MAC key appended to the *end* of the authenticated
>> data in the interior hash invocation, rather than prepended at the
>> beginning, as in HMAC.  This alteration renders the MAC method
>> virtually indistinguishable, cryptographically speaking, from the
>> one I proposed; in particular, if the underlying hash function is
>> not collision-intractable, then this handshake hash, as well, will
>> be vulnerable to collision attacks.
>The key difference between the SSL3 handshake hashes and your proposed
>MAC is that the SSL3 handshake hashes use two redundant MACs
>alternating MD5 and SHA.  In order to construct a hash collision you
>must have two messages that collide in both MD5 and SHA simultaneously.
>I contend that this makes the SSL3 handshake hashes

Well, I expect that the combination of MD5 and SHA is in some sense
*more* collision-intractable than either one used separately, but that
is simply an argument for using both in general message authentication,
not an argument for "weakening" the MAC method used in the handshake
hash.  The point is that the collision-intractability of the underlying
hash function is, in practice, a necessary condition for the security of
*any* of the proposed MAC methods, including HMAC.  If you don't believe
that, say, SHA is collision-intractable, then you shouldn't use it as
the (sole) basis for any of the known hash-based MAC methods.  (That is
why I brought up the question earlier of whether MD5 should be listed as
a hash function choice at all, given recent questions that have arisen
about its collision-intractability.)  On the other hand, if you *do*
believe that SHA is collision-intractable, then the MAC method used in
PCT, or for the SSL v3.0 handshake hash, is quite sufficient.  (One
could, it is true, consider a more subtle definition of
collision-intractability which, if met, would make a hash function
acceptable for HMAC but not for the MAC method used in PCT; however,
most of us would probably agree that discovery of an efficient
collision-finding algorithm for a cryptographic hash function would be
sufficient reason to reject it for use in either MAC method.)

In short, I see absolutely no reason for treating the "handshake hash"
any differently from other MACs; both must be secure under the normal
definition of a MAC.  And the MAC method used in the SSL v3.0 "handshake
hash" has that property, as long as the underlying hash function
(whether MD5, SHA or a combination thereof) is collision-intractable. 
The same can be said of the method used for general message
authentication in PCT.

				Daniel Simon
				Cryptographer, Microsoft Corp.

Received on Monday, 29 April 1996 14:35:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC