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

Pre-encrypted data

From: Tim Dierks <timd@consensus.com>
Date: Thu, 25 Apr 1996 19:51:44 -0700
Message-Id: <v02140b07ada5e085e48d@[205.149.165.24]>
To: ietf-tls (Transport Layer Security WG) <ietf-tls@w3.org>
In the recent discussion of the STLP "strawman", several issues have come
up; here are my thoughts on a few. For what it's worth, I'm in the middle
of implementing SSL 3.0 right now.

- Pre-encrypted data: I don't think pre-encrypted data is a good idea for
the following reasons:
 1) It violates the layer abstraction of the protocol as a transport;
you've got a server feeding pre-encrypted data into the layer, and the
client pulling decrypted data out of it. This seems like a fundamental
complication of the model, and just feels wrong.
 2) It's vulnerable to traffic analysis. Since any particular piece of
pre-encrypted data, when transmitted, will have the same representation on
the wire, I can determine what data people are accessing by watching their
transactions and correlating the results.
 3) It offers minimal benefit. I don't see how it can offer any security
benefit, since the information on how to decrypt the data has to be
available to the client anyway. I think the performance benefits are
minimal; some stream ciphers (such as RC4) are very fast, and if that's too
much to pay, or if the MACing is too expensive, I think the right thing to
do is to allow that to be driven by better implementations or improved
algorithms. For the hypothetical servers which are supplying a large
quantity of secure data, it doesn't seem inappropriate to require them to
make an investment in hardware encryption support to deliver high
performance.

 - Tim Dierks

Tim Dierks  --  timd@consensus.com  --  www.consensus.com
Head of Thing-u-ma-jig Engineering, Consensus Development
Received on Thursday, 25 April 1996 22:50:10 EDT

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