W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Re: Merged Transport Layer Protocol Development

From: Bennet Yee <bsy@cs.ucsd.edu>
Date: Mon, 22 Apr 1996 21:32:55 -0700
Message-Id: <199604230432.VAA25435@work.ucsd.edu>
To: ietf-tls@w3.org

Rather than discuss conspiracy theories, how about getting back to the
technical sides of TLS?

One aspect that I particularly liked about PCTv2 that is absent from
SSLv3 and the proposed merged protocol is the ability to handle
pre-encrypted data.  I believe that this is a very good way to
amortize the bulk cryptography overhead over many sessions for some
applications -- e.g., where images or text are being sold on a
subscription/per-item basis and the service provider would like to
make the data a little more secure so that network sniffers can not
trivially obtain it.

In such applications, reusing the same key for the data is not a big
deal, in that (1) while it exposes the data-encrypting key a little
more due to its being transferred to multiple recipients under
different session keys, it is up to the server to determine the amount
of this kind of exposure prior to re-encrypting the data with a fresh
key, (2) malicious subscribers have the ability already to
redistribute the data (or the key to the encrypted data, if the
subscriber has the ability to extract it from his/her browser).

When the server is willing to send the data only if it is possible to
transmit it in encrypted form, there would be no extra storage
overhead other than that for the bulk encryption key -- only the
pre-encrypted copy of the data would be needed -- and for most
transfers data may be streamed directly from the disk to the network
interface.

The same reasoning applies to pre-MAC'ing the data.

I believe it is good to expose this encryption cost -vs- communication
security tradeoff to the Web server administrators, and I believe that
it is generally useful for other "data broadcast / publishing"
applications.  One problem with existing SSLv2 and PCTv1 Web servers
is that the crypto overhead is sometimes unacceptably high, and this
is one way to ameliorate this.

-bsy

--------
Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114
Received on Tuesday, 23 April 1996 00:33:03 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:34:46 EDT