Re: Additional suggested cleanups for TLS

Dan and Phil,

  Please read below Dans comments.

Dan Simon wrote:
> 
> >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?

  I agree that there is no reason for using a weaker construction as
you indicate here Dan.  I do wonder it it is a matter of necessity from
a buisness point of view.  Knowing however that does not stand up under
scrutiny however.  I don't see why HMAC could not e a consideration or
a small tradeoff.

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

  Well, I do believe that Dan is correct here.  I remember and reviewed
some of the back discussions on this matter.  It would seem that a
seperate
key is "ONE" solution to this problem from Key Block.  I liked Hugo's 
approach alot better, as far as it went.  It should be explicit however 
and defaulting to HMAC if MAC is compermised or persumed so.  Or
possibly
a seperate extension of the current Cypher Suite that that will provide 
for that type of function.  The other would be to use a seperate 
configurable interface as I had suggested, and now am testing.  This
gives
more flexability in implimentation and provides for forward
compatability
with multi level defaulting.

  As far as "I" am concerned, neither suggestions stated here are
adequate
for a broad range of implimentations.  It would seem that little has
been
gained by myself in this belief here on this forum however.  So I will 
leave it at that, currently.  

Regards and Happy Hollidays,

> 
> (Thanks for pointing this out, Phil--I hadn't noticed this bug before.)
> 
>                         Daniel Simon
>                         Cryptographer, Microsoft Corp.
>                         (dansimon@microsoft.com)
> 
> >

-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. 
Phone :972-447-1878
E-Mail jwkckid1@ix.netcom.com