From: stewarts@ix.netcom.com
Date: Thu, 16 Oct 1997 07:26:44 +0800
To: Will Price <cypherpunks@cyberpass.net
Subject: Re: proposal: commercial data recovery
In-Reply-To: <199710140937.KAA01187@server.test.net>
Message-ID: <3.0.3.32.19971015113856.006aa938@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



At 02:34 AM 10/15/1997 -0700, Will Price, probably annoyed at the
flaming that PGP5.5 has received, flames out Adam Back's proposal
for not doing the right things for his perceived market.
But PGP5.5 doesn't do most of those same things either.

>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, 

As Ian and Ian have pointed out, this is bogus - 
the sender can't control the recipients' uses of the message.
At most the sender has a right to control who receives the
message _until_ the recipient gets it,
and if they don't trust the recipient, they shouldn't send it.

>the encryption must be end-to-end, and 
This is fine.

>the recipient must know exactly who else can decrypt the message.  

PGP 5.5 does not provide this; the message headers only provide KeyID
for each recipient, not the person using the keys, so the recipient
only knows those recipients whose KeyIDs he knows or can look up.
(Plus deadbeef attacks make even those suspect.)

>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.  

Again, this is bogus - if the recipient's computer is insecure,
then the data is insecure from the moment the recipient decrypts it,
a step that even PGP5.5 does not usually prevent :-)

>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.  

Bogus.  If you send critical data to a colleague entirely in the clear,
and sendmail eats it instead if delivering it to your colleague,
or the colleague's mailbox disk drive crashes before he reads it,
and you have wiped the only copy before confirming receipt of the message, 
you lose and PGP5.5 won't help any, since neither PGP5.5 nor the
PGP SMTP filters cause extra copies to be created.
If you do this sort of thing often, you need a new definition of critical.

What you need is automated message receipts, and the decryption system 
needs to offer your recipient a user-friendly way to send receipts
when he actually reads the message.  PGP5.5 doesn't do this 
(not its job - it's an encryption program, not a mail user agent) 
and the mail client's receipts aren't enough, since they don't know 
if your recipient could decrypt the message successfully  
(nor whether they could read the language it was written in,
nor whether the contents made any sense, 
nor whether the recipient agreed with the content of the message. :-)

>I'm truly amazed that you would attack in such a spiteful fashion

If you can't tell serious concerns from spite, your ego's in the way
(you've probably been reading too many negative reviews lately. :-)
There are serious problems with the PGP5.5 approach, even though it 
does solve real business problems that some of your real customers have,
or at least think they have.

>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

Only the choice of keys is under the sender's control, 
not the knowledge of what actual _people_ hold those keys or 
what the CMRKers will do with the data, or even whether they 
have received copies unless she mails copies them directly
In the PGP SMTP filter context, if the sender must include
certain keys to get the message delivered, that's a rather 
limited definition of "under the sender's control".

> each recipient knows who can read the message with no key escrow 

As above, the recipients don't know each other unless
they happen to have each others' KeyIDs on their keyservers,
and since PGP5.5 "elegantly" doesn't indicate whether a recipient
is there because the sender wanted them or whether they're CMRKers.
Sure, if there's only one real recipient, both sender and recipient
know the eavesdroppers, but if there's more than one real recipient,
there's no way to tell.

>using the same old PGP message format we all know and love without change, 
If you count 5.0 message format as "old" :-)  And while the
CMRK fields apparently were in 5.0 key record formats, they weren't used,
and the semantics are much different even if the syntax is the same.
Treating desired recipients and undesirable recipients the same
is one approach, but it doesn't accomodate people who want
secret sharing to prevent a single CMRker from recovering the message.

>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.
I'm not flaming Adam's proposal here; that's a job for another message :-)
In particular, it seems to be evolving, and I haven't figured it out yet,
nor am I convinced there is a way to adequately perform the purposes
of data recovery.
				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639