RE: Merged Transport Layer Protocol Development

More responses to David Kemp's comments inserted below....

>----------
>From: 	dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]
>
>Mr. Yee suggests that pre-encrypting images can eliminate server
>overhead for bulk crypto, but I don't see how.  If you have a large
>pre-encrypted file to transmit over SSL, then just renegotiate a
>NULL-WITH-NULL CipherSpec before sending the file, and resume the
>previous CipherSpec when it's done.  The only overhead is for two
>handshake exchanges, which shouldn't be a serious burden on the
>server.

There are two problems with this method:  

1)  The MAC key must therefore be transmitted along with the new
encryption key, and can therefore be no stronger than the previous
encryption key; and

2)  Once MACing has been turned off in the underlying connection, there
is no guarantee that an adversary can't intervene, block subsequent
"change cipher spec" messages, and start sending/receiving other
information to/from the parties (in the clear) when transmission of the
pre-encrypted data stream has been completed.

The method proposed in PCT v2, and in the STLP document, is to use the
connection's established MAC key to authenticate pre-encrypted data, but
to use a MAC method which still allows most of the MAC computation to be
done in advance.  In particular, the data to be authenticated is hashed
once, and this result is then hashed again with the MAC key prepended. 
This MAC method defends against all of the attacks against which HMAC is
designed to defend, and has only the one (known) drawback that a
collision in the underlying hash function directly produces a collision
in the MAC function.  It has the advantage, however, that the "interior"
hash computation can be performed in advance.  (Note that the MAC must
be computed on the encrypted data, since the plaintext is not
necessarily available, and the MAC value itself will not be encrypted. 
This changed order has no security impact, but makes MAC precomputation
infinitely easier to implement securely.)

In PCT v2, a special "key management" message is used to transmit an
encryption key to be used to decrypt pre-encrypted data, which is then
authenticated as described above.  (Another "key management" message
restores the previous encryption key.)  In the STLP document, it was
proposed that the "change cipher spec" message be used for the same
purpose.  If that solution is unacceptable, then a compromise approach
might be to change the MAC function as described above, and to implement
pre-encrypted data support at the application level for encryption and
at the protocol level for message authentication.  In other words, the
encryption key would be transmitted as application data, the cipher spec
would then be switched (using an unmodified "change cipher spec"
message) to null encryption with normal message authentication, and the
pre-encrypted data would be transmitted as if unencrypted, with the
precomputed interior hash values for MAC computation used to compute
MACs quickly on the fly.

>On the other hand, creating a totally separate set of handshake
>messages to support pre-encrypted data is just another potential
>place for security holes to pop up.  I admit to not having studied
>the PCT 2.0 pre-encryption specs in detail, but before spending time
>doing so I'd like to see answers to the following:
>
>1) How much time does the PCTv2 pre-encryption handshake save over
>the standard SSLv3 resume-session handshake?, and

The answer to this question depends, of course, on the cost in CPU time
of performing encryption and hashing.  A ballpark figure might be on the
order of a second per megabyte of data.  This cost virtually disappears
if the data is pre-encrypted and pre-hashed; if a single encrypted
stream is accessed thousands of times a day, then I would say that the
savings begin to add up.

>2) if the answer to 1 is greater than epsilon, what analysis has been
>done to show that the pre-encryption handshake does not introduce
>new vulnerabilities to the protocol?
>
The PCT v2 spec has been fairly extensively reviewed, both internally
and externally.  The STLP document is, of course, a very rough sketch
rather than a full spec, and would obviously need to undergo a great
deal more scrutiny before any conclusions are drawn about its security
properties.

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

>

Received on Wednesday, 24 April 1996 19:13:19 UTC