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

RE: Merged Transport Layer Protocol Development

From: Dan Simon <dansimon@microsoft.com>
Date: Thu, 25 Apr 1996 13:42:30 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-92-MSG-960425204230Z-30773@tide21.microsoft.com>
To: "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'dpkemp@missi.ncsc.mil'" <dpkemp@missi.ncsc.mil>
> 
>From: 	dpkemp@missi.ncsc.mil[SMTP:dpkemp@missi.ncsc.mil]

>From: Dan Simon <dansimon@microsoft.com>
>Date: Wed, 24 Apr 1996 16:13:16 -0700
>
>> >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.
>
>The cost of the handshake does not depend on the amount of data
>subsequently protected by it (i.e. the size of the pre-encrypted,
>pre-hashed file).  The cost is fixed, and is incurred once each time
>the CipherSpec is renegotiated (at worst, twice for each pre-encrypted
>file; less if multiple pre-encrypted files are sent in a row).
>I believe the processor cost of a resume handshake to be fairly
>small; the 2 round trips might cause a slight communication delay but
>shouldn't affect the server load.

What is apparently being proposed here is that pre-encrypted data be
handled through a new handshake.  If this is to be done, then the
handshake itself must be modified to allow transmission of specific,
fixed encryption and MAC keys, as opposed to the normal derivation
process, which produces keys dependent on random challenges and the
like.  (The adapatation of the "change cipher spec" message in the STLP
document is just such a modification.)  Obviously, the addition of
another public-key operation to the server's load should be avoided if
possible; the natural solution is therefore to deliver the keys used for
pre-encryption using keys exchanged and derived through a normal
handshake.  Hence the method used in PCT v2, and in the STLP document.

Unless I've misunderstood the proposal, it sounds like we agree....


				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com
Received on Thursday, 25 April 1996 16:44:30 EDT

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