firewalls and CKE (fwd)

[Adam Shostack]

Marcus Ranum posted this to firewalls.  Contains some interesting
technical arguments against key escrow at the firewall level.


----- Forwarded message from Marcus J. Ranum -----

>From firewalls-owner at GreatCircle.COM  Mon Mar 25 21:26:27 1996
From: "Marcus J. Ranum" <mjr at clark.net>
Message-Id: <199603252204.RAA01115 at clark.net>
Subject: Re: firewalls and CKE
To: mckenney at smiley.mitre.org (Brian W. McKenney)
Date: Mon, 25 Mar 1996 17:04:41 -0500 (EST)


Brian W. McKenney writes:
>I missed the jist of the original message

	The gist of the first message was that software
key escrow is here, and it is the greatest thing since the
discovery of fire. :)  Granted, it's nice that someone
has found a way of convincing the government to let them
export good crypto, but in this particular application it makes
no sense.

>For the firewall-to-firewall encryption
>scenario, the data recovery component (DRC) may be a machine that
>intercepts (in real-time) the traffic and then decrypts the data (recovers
>the data).  The interception of encrypted data makes sense for this type of
>communication since the data is not really stored on the firewall (it is
>wrapped/unwrapped quickly).  [the intercepted packet may be copied and then
>decrypted]

	That's completely brain-damaged if you think about it for
a second.

	Let's suppose I have a file and it is unencrypted. I
FTP it through my SKE-equipped firewall to the Paris office. 
My file gets transparently encrypted as it is broken into packets
and sent across the 'net. Then - what - someday I need the file
back so I get the escrowed key and reassemble the file from
raw packets? That's dumb! I dunno about you but I'd just recover
the clear file from a backup tape. :)

	Firewall-to-firewall encryption is a link-layer security
technology.  It encrypts data in transit: before it leaves and
after it arrives you *already* have a clear-text un-escrowed
version of the data. If I have a corporate requirement
to "escrow" my telnet sessions then I'll use a version
of telnet that logs keystrokes. But I can't see any reason
(unless I'm a spook) to de-archive, de-escrow, and reassemble a
telnet session for archival purposes.  It gets worse since
all the "escrowed" packets will be mishmoshed in with DNS queries
(all "escrowed") and NFS packets and lordy knows what else. If
it came to having packet records, why not simply log all
packets *before* they get encrypted at the firewall, while
they are still in the clear? Easier, no?

 	At least LOTUS' "key escrow" approach is openly
designed for the spooks and doesn't pretend to add value to
the end user.

	I appreciate that TIS has made a successful deal with
the devil to export some strong encryption, but it's unfortunate
that they're showcasing it in a way which makes absolutely no
sense at all.  It's a shame, because basically we're seeing
smart people doing technically goofy things in order to
comply with some ridiculous laws.

mjr.

----- End of forwarded message from Marcus J. Ranum -----