[711] in cryptography@c2.net mail archive
Re: Concern over Netscape announcement and GAK
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Tue May 6 14:59:01 1997
To: Marc Horowitz <marc@cygnus.com>
cc: sameer <sameer@c2.net>, cryptography@c2.net, jsw@netscape.com
Date: Tue, 06 May 1997 14:45:09 -0400
From: Steven Bellovin <smb@research.att.com>
sameer <sameer@c2.net> writes:
>> So while I accept that Netscape may not be consciously
>> planning to implement GAK in their products, the Netscape announcem
ent
>> is still a very sad thing, as the government has effectively coerce
d
>> Netscape into implementing a GAK-future without them even realizing
>> it.
I think you're becoming a little too melodramatic.
At this point, I have to be on Netscape's side. Key recovery for
email and similar applications in a corporate environment *is* a valid
customer requirement. That the government could abuse it for
nefarious purposes is unfortunate, but that doesn't make it any less
valid.
Yup. One more point to bear in mind. There is, as noted, little reason
to escrow a used SSL key; ordinary backup procedures should suffice for
that. But (in my perception; bear this qualifier in mind) Netscape isn't
selling just Web browsers and servers. Rather, they're selling a network
operating system package. There are many other uses for cryptography in
such a setup. To give one example, suppose, over the SSL-protected (and
authenticated) channel, a new public key is sent; this key is used to
superencrypt credit card numbers. (Suitable HTML hacks to control this
are left as an exercise for the reader.) The purpose is to avoid having
cleartext credit card numbers anywhere on the Web server machine, even
temporarily; rather, they're passed through to a secure backend machine.
They're even stored encrypted. And once you start storing encrypted
material, you need key recovery.
Any sort of records cut both ways. It doesn't matter whether or not
they're encrypted; if they exist, someone else can get them. Key
recovery is a strategy for protecting yourself against one threat;
in some cases, it exposes you to others. By various technical means --
key-splitting, for example -- you can minimize one threat but raise
another. This is nothing new; it's an engineering tradeoff. The
technical challenge is finding mechanisms that allow for more choices
and more tradeoffs; one size does not fit all.
