From: “Marcus J. Ranum” <mjr@clark.net>
To: mckenney@smiley.mitre.org (Brian W. McKenney)
Message Hash: b03a23026c55e4f72fe0a9d47166e9706b71f8b188ee82f0599e982c2bcb4623
Message ID: <199603252204.RAA01115@clark.net>
Reply To: N/A
UTC Datetime: 1996-03-25 22:04:41 UTC
Raw Date: Mon, 25 Mar 1996 17:04:41 -0500 (EST)
From: "Marcus J. Ranum" <mjr@clark.net>
Date: Mon, 25 Mar 1996 17:04:41 -0500 (EST)
To: mckenney@smiley.mitre.org (Brian W. McKenney)
Subject: Re: firewalls and CKE
Message-ID: <199603252204.RAA01115@clark.net>
MIME-Version: 1.0
Content-Type: text/plain
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 -----
Return to March 1996
Return to ““Marcus J. Ranum” <mjr@clark.net>”
1996-03-25 (Mon, 25 Mar 1996 17:04:41 -0500 (EST)) - Re: firewalls and CKE - “Marcus J. Ranum” <mjr@clark.net>