- From: David P. Kemp <dpkemp@missi.ncsc.mil>
- Date: Thu, 25 Apr 1996 11:52:08 -0400
- To: ietf-tls@w3.org
From: Dan Simon <dansimon@microsoft.com>
Date: Wed, 24 Apr 1996 16:13:16 -0700
> There are two problems with this method:
[negotiating NULL-WITH-NULL then resuming encryption - dpk]
>
> 1) The MAC key must therefore be transmitted along with the new
> encryption key, and can therefore be no stronger than the previous
> encryption key; and
>
> 2) Once MACing has been turned off in the underlying connection, there
> is no guarantee that an adversary can't intervene, block subsequent
> "change cipher spec" messages, and start sending/receiving other
> information to/from the parties (in the clear) when transmission of the
> pre-encrypted data stream has been completed.
I don't understand these objections.
The initial state of an SSL connection is NULL-WITH-NULL (no) security.
The handshake proceeds from that state to a non-NULL CipherSuite in
a manner that I believe to be immune to known protocol attacks. If
that weren't the case, then the initial MAC key would be "no stronger
than the previous encryption key", i.e. zero.
The finished message (which authenticates all prior handshake messages)
is an important component of preventing problem 2).
If there is a protocol weakness in the SSL handshake that causes it to
be subject to problems 1) and 2), then it affects all of SSL, not just
using the handshake to accommodate pre-encrypted data. I am not aware
of any such weakness.
> >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.
Received on Thursday, 25 April 1996 11:52:25 UTC