RE: Merged Transport Layer Protocol Development

>
>From: 	Jeff Weinstein[SMTP:jsw@netscape.com]

>Dan Simon wrote:
>> 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.
>
>  I think you misunderstand the purpose of using both MD5 and SHA for
>the handshake hash.  If SHA were compromised we could just deprecate
>all cipher suites that included SHA, without having to immediately
>change the base protocol, since the handshake hash includes MD5 as
>well.  If the handshake hash were just SHA, then we would have to
>change
>the protocol if it fell.

On the other hand, if *both* MD5 and SHA were to be broken, then the
protocol itself *would* have to be changed (in fact, even if only one of
them falls, then the protocol *should* be changed anyway, by the above
logic, to maintain this "extra security" claimed for the handshake
hash).  But if the handshake hash were treated like any other MAC, then
*all* problems caused by hash functions dying an unnatural death could
be handled simply by adjusting the set of valid cipher suites (or better
yet, by deleting an individual hash function code, once the "cipher
suites" are divided up--as they should be--into separate codes for
ciphers, hash functions, etc.).  And as long as hash functions can be
expunged from the protocol once they are found not to be
collision-intractable, the MAC method used in PCT would be a perfectly
satisfactory one for all MACs in the protocol, including the handshake
hash.  

				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com


>

Received on Tuesday, 30 April 1996 14:28:28 UTC