From: Anonymous <nobody@REPLAY.COM>
Date: Mon, 13 Oct 1997 11:43:33 +0800
To: cypherpunks@cyberpass.net
Subject: Auto-archiving cleartext is GAK
Message-ID: <199710130335.FAA19075@basement.replay.com>
MIME-Version: 1.0
Content-Type: text/plain



Advocates of the model where software is automatically archived on
receipt, either in cleartext or re-encrypted with a corporate key,
need to be aware that there are problems with it:

No notification to sender about the policy.

Imagine encrypting this mail to your friend sue@microsoft.com: "Hey Sue -
it's been a while.  Is your boss still being such a wiener?  That was a
great imitation you did of the jerk at the party last month.  He still
doesn't know you're shopping your resume around, right?  What a luser."
You might have thought you had a certain level of privacy when you
encrypted it to your friend's personal key, but you didn't.  This is going
to cause embarrassment and misunderstandings.  People should know if their
mail is going to be automatically saved in the clear to a company archive.
The best way to make sure of that is to have the sender be the one to do
it, or not.

No way to prevent third-party access.

With the corporate message recovery feature, the sender has the
option of simply ignoring the recovery key and sending it encrypted just
to the recipient.  Some corporations won't let it through, others will.
Some companies will want mail to be made recoverable by default, while
still allowing an escape clause for personal mail and special purposes
(like for "sensitive" mail which needs protection against subpoena
and discovery).  They can use the "optional" CMR mode.  Again, senders
are always notified as to which mode is being used by a given company,
and senders can be confident that if they don't use the third-party key,
no access will be possible.  With automatic encryption and archival on
receipt, all mail will be archived, and senders have no notice and no
guarantee that stated policies will be followed.

No escape via super-encryption.

Even if the company is mandating a recovery key and filtering out
messages which aren't encrypted to it, the sender still has the option to
super-encrypt with the recipient key alone, before sending the message
encrypted to the corporate recovery key.  This ensures that only the
recipient's personal key can read the message.  With software which
automatically saves the cleartext of the message, once the user reads
the data it is available to the corporation via the snoopware.

Facilitates GAK!

Suppose this solution is adopted, and software is developed which
automatically re-encrypts received email and sends it to a secure archive.
It's robust and works with a wide variety of email packages.  Now the
government could simply mandate this to be used for all mail reading
software.  The secure archive would be a remote archive maintained by
the FBI to protect public safety.  All plaintext would be sent there,
encrypted by the FBI key.  The business software would already support
this.  This is GAKware!  Unlike with a CMR system, the sender would
have no way to prevent access.

Can't handle forgotten passphrases.

People forget passphrases all the time.  With re-encryption on receipt,
there is no way to recover gracefully from this error.  All the incoming
encrypted data is lost until you can notify everyone who has sent mail to
resend it, and get your new key out to all of them.  These may be purchase
orders, sales leads and other important documents which represent lost
business if they can't be recovered.  This is going to invite people to
use poor security practices like writing down passphrases or choosing
ones which are easy to guess.  Worse, it...

Invites key escrow.

In order to prevent this problem, employees may be forced to share
their secret keys with corporate management.  Software will be written
to facilitate this process.  Crypto companies are already doing this.
Nortel Entrust allows key generation by management, where employees
are given the keys and management keeps a copy.  Shades of Clipper!
This also fails the notification requirement.  Don't believe me?  Take a
look at this description of the Nortel Entrust product:

> Recovering Lost Keys
>    
>    Many data security systems require that users have passwords to access
>    their keys. However, with some information security systems, disaster
>    strikes when users forget their passwords. When users of such systems
>    forget their passwords, not only do they lose their keys -- they also
>    lose all the information encrypted with those lost keys (forever).
>    Entrust, however, provides an easy way to securely recover keys.
>    
>    If users forget their Entrust passwords, they call their Entrust
>    Administrator to request that their encryption key pairs be recovered.
>    After setting up the users for key recovery using Entrust/Admin, the
>    Entrust Administrator provides each recovered user with a new
>    reference number and authorization code. Users then enter this
>    information as part of the Recover User operation in Entrust/Client.
>    This operation sets up a protected communication session between
>    Entrust/Client and Entrust/Manager for encryption key pair recovery.
>    When Entrust/Client recovers a user's encryption key pair, it
>    automatically creates a new signing key pair.
>    
> Updating Keys
>    
>    While users can recover their key pairs if they forget their
>    passwords, there are some situations in which users may want to get
>    new key pairs altogether. For instance, the security policy of an
>    organization may dictate that users get new key pairs every two years.
>    In this case, a Security Officer uses Entrust/Officer to specify that
>    key update occurs every 24 months. The term key update refers to the
>    automatic creation of new encryption key pairs and signing key pairs
>    at specified times. Any Security Officer can specify the frequency of
>    key updates.
>    
>    Every time users log on to Entrust, the software checks to see if key
>    update is required. If this is the case, Entrust/Client makes a
>    request to Entrust/Manager for a new encryption key pair. Once the new
>    encryption key pair is generated, Entrust/Manager delivers the new key
>    pair in a protected communications session. Delivery of the new
>    encryption key pair is completely transparent to the user.

No system is ideal.

Before pushing this re-encryption model as a panacea, think about the
implications.  No system which provides automatic access to business data
is going to be privacy friendly.  Any such system can be perverted into
supporting GAK.  Load it up with all the disclaimers you like, but if
you advocate software which contains key escrow and which automatically
provides cleartext to third parties, you are not advocating software
which protects privacy.  Be prepared to be called an advocate of GAK next
time you push for software which automatically archives cleartext, because
if it can save it for business, it can save it for government.