Re: Merged Transport Layer Protocol Development

Dan Simon wrote:
> 
>> From:  Eric Murray[SMTP:ericm@lne.com]
>>
>> Yes, if the preencrypted data has been encrypted by something
>> stronger than TLS offers, and the key is sent via a TLS session,
>> then the TLS session becomes the weakest part of the link.  I'm
>> not sure that's really a big problem.  First off, more than one
>> proposal for TLS-type protocols have included triple-DES
>> as a symmetric cipher choice.  If I'm not mistaken, triple-DES
>> is the strongest commonly-available symmetric cipher.  So the
>> preencrypted data key would, if one used the best possible TLS
>> ciphertypes, be as secure as the preencrypted data itself.
>> Secondly, the suggested MAC method to allow some pre-calculation
>> of the MAC is not as secure as the Krawczyk method used in SSL3
>> (and I would presume STLP).
> 
> 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
collision-intractable.

-- 
Sure we spend a lot of money, but that doesn't mean | Tom Weinstein
we *do* anything.  --  Washington DC motto          | tomw@netscape.com

Received on Friday, 26 April 1996 19:03:38 UTC