RE: Additional suggested cleanups for TLS

>From: 	Phil Karlton[SMTP:karlton@netscape.com]
>
>Another issue concerns the MAC for the Finished messages. There was MUCH
>discussion about whether they should be constructed like HMAC rather
>than the ad hoc algorithm that was chosen. The tradeoffs are fairly
>simple.
>
>   pro) Using HMAC is more secure (probably).
>
>   con) The server has to retain the entire handshake until it
>	can compute the master_secret. The storage requirements
>	for heavily used secure servers could be prohibitive.
>	(Some information, e.g. the server's certificate chain
>	is probably constant across all handshakes; and that
>	helps a little.)

On the other hand, there's simply no justification for using a weaker
construction in the (more crucial) finished message than in the standard
data MAC.  Since you vehemently opposed anything weaker than HMAC for
data MACing, even for the sake of efficiency (right here on this mailing
list, in fact, when we were discussing pre-MAC'd data), I assume you'd
never support using a weaker function in the finished message--right,
Phil? 

In any event, the function used in SSL 3.0's finished message is flawed,
in that the master secret is used as the key, with both MD5 and SHA
being used for extra anti-collision protection.  That means that if
*either* hash function turns out to be invertible as used there, then
the finished message ends up revealing the master secret.  At the very
least, a separate key should be derived from the key block for this
purpose.  Better still, the value in the finished message should be a
MAC of the previous handshake messages using this separate key, where
"MAC" is a separately defined primitive (as per Hugo's suggestion),
specified (implicitly or explicitly) by the pending cipher suite (and
presumably defaulting to HMAC for current cipher suites).  That way, if
the current choice of MAC falls under suspicion, it can be assumed
replaceable in every implementation.

(Thanks for pointing this out, Phil--I hadn't noticed this bug before.)


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

>

Received on Wednesday, 18 December 1996 18:09:31 UTC