Re: Merged Transport Layer Protocol Development

I just wish to say that I also agree that special processing for
pre-encrypted data is a Bad Idea.  A 90-MHz Pentium can encrypt fast
enought to completely fill an ethernet (the ethernet becomes the
limiting factor), and the processing speed is doubling every year.

The overhead from encryption is negligible all but the most
high-volume servers connected to the Internet by something faster than
10Mbits/sec.  (Unless you also do a lot of CPU-intensive processing
that competes for CPU.)

I don't think the complications from special handling are justified.

As for pre-encryption with strong hardware algorithms, it does no harm
to double-encrypt.

    Tatu


> 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 18:06:58 UTC