Re: Stream Cipher Transform -- revisited

"Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <tld5032@commanche.ca.boeing.com> Wed, 31 July 1996 00:21 UTC

Received: from relay.hq.tis.com by neptune.TIS.COM id aa29984; 30 Jul 96 20:21 EDT
Received: by relay.hq.tis.com; id UAA00802; Tue, 30 Jul 1996 20:24:24 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000796; Tue, 30 Jul 96 20:23:55 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05709; Tue, 30 Jul 96 20:23:27 EDT
Received: by relay.hq.tis.com; id UAA00793; Tue, 30 Jul 1996 20:23:54 -0400
Received: from atc.boeing.com(130.42.28.80) by relay.tis.com via smap (V3.1.1) id xma000791; Tue, 30 Jul 96 20:23:31 -0400
Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA26679; Tue, 30 Jul 1996 17:09:10 -0700
Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA258358450; Tue, 30 Jul 1996 07:54:10 -0700
Received: by commanche.ca.boeing.com (AIX 4.1/UCB 5.64/4.03) id AA21468; Tue, 30 Jul 1996 07:55:10 -0700
Message-Id: <9607301455.AA21468@commanche.ca.boeing.com>
To: Germano Caronni <caronni@tik.ee.ethz.ch>
Cc: ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, markson@incog.com, dpalma@netcom.com, Project SKIP <skip@tik.ee.ethz.ch>, Burkhard Stiller <stiller@tik.ee.ethz.ch>, Bernhard Plattner <plattner@tik.ee.ethz.ch>
Subject: Re: Stream Cipher Transform -- revisited
In-Reply-To: (Your message of Wed, 03 Jul 96 14:42:10 +0200.) <199607031242.OAA10521@kom30.ethz.ch>
Date: Tue, 30 Jul 1996 07:55:09 -0700
From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <tld5032@commanche.ca.boeing.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

Germano

Apologies, I have been intending to reply but summer kept getting in
the way.  Anyway a couple comments and thoughts on including support
for stream ciphers in IPSEC as I believe there is a strong security
and business case for their use.

1) In general most of us have substantial numbers of legacy systems or
over-subscribed systems which have minimal amounts of un-used cycles.
It is very difficult to justify, and often to operationally implement,
a high-overhead encryption mechanism which results in the capacity of
100 user production server being reduced to 60 or 70.

2) In many cases absolute security of the data may not be justified
but prevention of re-play attacks or session-hijacks is essential,
especially in light of on-going work on "single sign-on functions".
It would seem that light weight ciphers might be ideal here.

3) For now, regardless of our personal views, exportability of a
solution is very important.  It seems likely that ciphers may be more
generally exportable and having more exportable options would appear
to be win.

4) As you note, protection of "content" from alteration during delivery
is also key, whether you are working with "web data", realtime video, or
voice.  Again the low-overhead of ciphers looks attractive for this
type of use.

I encourage your group to continue the work as I believe that support
of low-overhead encryption techniques will considerably broaden the
usability of IPSEC.

Take care

|   Terry L. Davis, P.E.   |  Boeing Information & Support Services    |
|       206-957-5325       |  tld5032@atc.boeing.com.                  |
   --------------- Tuesday July 30,1996 07:27 AM PDT -------------