1997-10-15 - Re: proposal: commercial data recovery

Header Data

From: Will Price <wprice@pgp.com>
To: Adam Back <ietf-open-pgp@imc.org
Message Hash: 860692762c82b68544ac463849ef885f4886721d89f54aa6dc40c949585a7101
Message ID: <v04001b0eb06a3d206797@[205.180.137.244]>
Reply To: <199710140937.KAA01187@server.test.net>
UTC Datetime: 1997-10-15 09:38:36 UTC
Raw Date: Wed, 15 Oct 1997 17:38:36 +0800

Raw message

From: Will Price <wprice@pgp.com>
Date: Wed, 15 Oct 1997 17:38:36 +0800
To: Adam Back <ietf-open-pgp@imc.org
Subject: Re: proposal: commercial data recovery
In-Reply-To: <199710140937.KAA01187@server.test.net>
Message-ID: <v04001b0eb06a3d206797@[205.180.137.244]>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam:

First, let me state some overriding design goals of a data recovery system
required to ensure privacy: the sender must know and consent to every key
that will be able to read the message during its lifetime, the encryption
must be end-to-end, and the recipient must know exactly who else can
decrypt the message.  The sender's privacy is paramount as it is their data
which is being trusted to the system.  These are basic principles not only
of a data recovery system, but for any cryptosystem.

The design you have been espousing for the last week or so in your many
messages takes the power out of the hands of the sender and encourages
automated violations of the sender's privacy by the recipient (perhaps even
unbeknownst to the recipient).  In your model, the recipient automatically
decrypts and then re-encrypts to a data recovery key -- even though
end-user computers are likely to be insecure thus making this decrypt &
reencrypt step rather specious at best.  The only information the sender
has before sending the message is "your message might be able to be read"
by someone else, or more likely no information whatsoever as there is no
need to put such information in the protocol as far as the format is
concerned.  Either way, the sender is thus easily led into a false
assumption of security.  The encryption is not end-to-end but rather is
completely unwrapped in the middle and then rewrapped introducing serious
security flaws, and the sender has no idea to whom the message will be
auto-reencrypted by the receiver.

As an actual data recovery system, it also fails fundamental tests.  If I
encrypt critical data to a colleague wiping it from my system after
sending, then the colleague is incapacitated before receipt and processing
of the message, the data can never be retrieved.  A data recovery system
must solve this kind of issue -- data recovery here means that from
end-to-end the data is recoverable in case of emergency.  One cannot ignore
message transit time in this -- it can take days for a message to travel
from AOL to the outside world.  If you don't need data recovery, don't use
it, but at least respect the people who do need it and need it to actually
work at all points.

>With these three principles you still have lots of flexibility because
>you can escrow storage keys

I'm truly amazed that you would attack in such a spiteful fashion a simple
system which adds a recipient-requested, sender-approved extra recipient
which is end-to-end wherein all recipients are under the sender's control
and each recipient knows who can read the message with no key escrow using
the same old PGP message format we all know and love without change, and
yet you propose a much less secure system which allows hiding critical
information from the sender and does not adequately perform its stated
purpose of data recovery.

- -Will


Will Price, Architect/Sr. Mgr.
Pretty Good Privacy, Inc.
555 Twin Dolphin Dr, Ste.570
Redwood Shores, CA 94065
Direct (650)596-1956
Main   (650)572-0430
Fax    (650)631-1033
Pager  (310)247-6595
wprice@pgp.com
Internet Text Paging: <mailto:1333485@roam.pagemart.net>
<pgpfone://clotho.pgp.com>
<http://www.pgp.com>

PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x5797A80B>


-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5

iQA/AwUBNESODay7FkvPc+xMEQIVuACfZwywDZSvGlsxefZuTyO6A+TFxlUAn39a
0FkpIVd4jcAIYpVNpIpofdSB
=nj0q
-----END PGP SIGNATURE-----






Thread