RE: Merged Transport Layer Protocol Development

> 
>From: 	Eric Murray[SMTP:ericm@lne.com]
>
>My suggestion would be that the current spec (SSL3) has
>a method already, as someone else has proposed, to
>enable sending pre-encrypted data by changing the cipherspec
>to RSA_WITH_NULL_SHA or RSA_WITH_NULL_MD5 or
>even NULL_WITH_NULL_NULL and sending the pre-encrypted
>data unencrypted by the TLS layer.

If this solution (NULL_SHA or NULL_MD5) is used, then the MAC must be
computed (as I mentioned) on the ciphertext rather than the plaintext,
since the cleartext will not be available for MACing.  And if pre-MACing
is to be made possible, then the MAC method must be changed from HMAC to
the one I described.  

>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 reason for their modification of the MAC method in this case is
obvious:  to avoid having to keep all the handshake messages around
until the MAC key is exchanged.  The overhead would have been minor
(compared to the cost of repeatedly encrypting huge data streams), but
it was enough to prompt the "weakening" of the MAC method in this case.

Personally, I agree with this decision, because I believe the modified
MAC method to be quite sufficiently secure--much, *much* more so than,
say, the effectively 40-bit-key-based MACs that would typically result
if pre-MAC keys had to be sent at the application layer, as suggested by
some opponents of explicit support for pre-encrypted data.

>So, I'm not sure that sending the pre-encrypted data's key
>via TLS is any weaker than the preencrypted data itself, and I do
>see a problem with using a weaker MAC method.  On the other hand, SSL
>already has a method to deal with preencrypted
>data, although it's not as streamlined as some would like.
>My opinion would be that the cost of adding more to the protocol
>(time spent arguing about it here, plus time taken to comb over
>it looking for possible security holes) isn't worth the gains in
>this case.  It's worth thinking about later as an addition to
>the TLS protocol, but I'd rather see this WG get out something basic
>that works soon instead of something complicated later.
>

I'm confused.  What is this method that SSL "already" has?  As far as I
can tell, what people have been proposing is that the security of the
channel be turned off entirely to make way for pre-encrypted data (how
the security properties are to be turned back on again, or how to
protect the remainder of the connection from spoofing if they're not, is
beyond me).  Is this really more secure than the modification I proposed
to the MAC function?

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



>
>
>

Received on Thursday, 25 April 1996 16:42:20 UTC