Re: Additional suggested cleanups for TLS

HUGO@watson.ibm.com wrote:

> I will not get into the discussion of whether retaining the entire handshake
> data until master_secret is computed is a real problem or not.

As I said before, I think this is the main discussion to have. The costs
can be considerable; maybe they just have to be paid, but that decision
should not be taken lightly.

> If it is decided that it is not a real problem just go with HMAC on
> the full handshake data.

I concur.

> If it is decided that it is a problem then it still does not justify going
> to ad-hoc constructions.
> Just define that you compute
> MAC(master_secret, HASH(handshake_messages+Sender))

To a a certain extent, this is also an ad hoc construction. :-(

> where HASH is a plain (unkeyed) hash function , e.g. SHA.
> In this case you can still use the generic specification with MAC
> (and whatever realization of MAC you choose to use),
> and you also make clear that you authenticate  HASH(handshake_messages+Sender)
> rather than the full handshake_messages. (Which means that you assume your HASH
> to be collsion-resistant).

... which is something I am only willing to assume on even days. :-( One
mitigating factor is that the collision would have to be computed in
real time (before the connection timed out) for a successful MITM
attack.

> As for computing two MAC's, one based on SHA and one on MD5, you can still
> choose to do that.

I would be more comfortable doing the concatenation of the two MACs as
the content of the finished messages.

> Though, it will be probelmatic to  define using a single
> generic MAC notation.

The notational inconvenience is secondary. The words can be clear enough
so that independent implementations can interoperate.

> As Dan Simon said, if you do so you MUST use two different keys for
> each of the MAC algorithms.

Using 2 different derived keys (as opposed to the master secret) is
indeed a better idea.

PK
--
Philip L. Karlton		karlton@netscape.com
Principal Curmudgeon		http://www.netscape.com/people/karlton
Netscape Communications Corporation

    Everything should be made as simple as possible, but not simpler.
	-- Albert Einstein

Received on Friday, 27 December 1996 20:13:19 UTC