Re: Merged Transport Layer Protocol Development

> From: Ralph Spencer Poore <rspoore@ralph-s-poore.com>
> 
> At 09:32 PM 4/22/96 -0700, you wrote:
> >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.
> >
> >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.
> 
> I agree.  Support for pre-encrypted or pre-MAC'ed data also permits the use
> of very secure hardware implementations of cryptography for highly sensitive
> data without impacting the server software implementation which might be
> unable to meet trusted system criteria or other high-security policy of an
> organization.


I disagree.  Support for pre-encrypted or pre-MAC'ed data is *only* an
efficiency hack, and even then one with negligible or zero benefit over SSL.

If you want to pre-process data with a very secure implementation
(in the Govt. we call it "Type 1" encryption), you're certainly free
to do so.  SSL doesn't know or care whether the application-data
presented to it is plaintext or super-encrypted; it's all treated
the same, using the current CipherSpec.

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.

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

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?

Received on Wednesday, 24 April 1996 12:39:46 UTC