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@GreatCircle.COM Mon Mar 25 21:26:27 1996 From: "Marcus J. Ranum" <mjr@clark.net> Message-Id: <199603252204.RAA01115@clark.net> Subject: Re: firewalls and CKE To: mckenney@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 -----