W3C home > Mailing lists > Public > ietf-tls@w3.org > October to December 1996

Additional suggested cleanups for TLS

From: <HUGO@watson.ibm.com>
Date: Fri, 27 Dec 96 16:18:27 EST
Message-Id: <199612272148.QAA59616@mailhub1.watson.ibm.com>
To: karlton@netscape.com, dpkemp@missi.ncsc.mil
cc: ietf-tls@www10.w3.org
Ref:  Your note of Tue, 17 Dec 1996 11:17:25 -0800 (attached)

Philip L. Karlton writes:
 > >  2) Mixing MD5 and SHA in a single ad-hoc function probably doesn't
 > >     buy anything because it is difficult to imagine a situation in
 > >     which SHA is broken but MD5 remains sound.
 > I have a pretty good imagination. :-)

I am paid to have imagination...
As explained in a  previous message, this is not an issue of wild
imagination. I advise against mixing of MD5 and SHA in HMAC based on
the analytical results that we have on these functions, and everything
we know about the comparative strength of SHA vs MD5.

 > 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.)

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.
If it is decided that it is not a real problem just go with HMAC on
the full handshake data.
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))

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).

As for computing two MAC's, one based on SHA and one on MD5, you can still
choose to do that. Though, it will be probelmatic to  define using a single
generic MAC notation.
As Dan Simon said, if you do so you MUST use two different keys for
each of the MAC algorithms.

I personally believe that this is not worth the complexity though
concatenating -- as opposed to mixing -- two MACs cannot be weaker than
doing only one (at least if you use two independent keys to key the MACs).


 > 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 16:48:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC