1997-10-15 - what can we do about PGP sell out and CMR?

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: tcmay@got.net
Message Hash: 8cb17380bcf9d70c7d60895a69b309283aae8feb776c147759317dd2cde98ace
Message ID: <199710152229.XAA01119@server.test.net>
Reply To: <v03102801b06ac04e5a12@[207.167.93.63]>
UTC Datetime: 1997-10-15 23:04:34 UTC
Raw Date: Thu, 16 Oct 1997 07:04:34 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 16 Oct 1997 07:04:34 +0800
To: tcmay@got.net
Subject: what can we do about PGP sell out and CMR?
In-Reply-To: <v03102801b06ac04e5a12@[207.167.93.63]>
Message-ID: <199710152229.XAA01119@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




The 3 main GAK-hostile design principles are also independently good
security principles in protecting communications traffic.  There are
ways to acheive data recovery functionality without CMR.  I think I
have demonstrated amply what these methods are, and have given a
design methodology for designing such systems.  PGPers are just not
interested to hear.

>From Bill Stewart's report, given the apparent amount of effort PGP
have put into their CMR based enforcement policy functionality, I
predict they won't remove CMR whatever we, or Schneier, or anyone else
says or proves about more secure less GAK-friendly ways of
implementing corporate data recovery.  I also suspect they won't
listen to Tim's earlier argument that they do nothing about recovery
of messages rather than implement GAK.

This quote should give us clue as to why they will continue with CMR: 

	"we're a real company with accountants"

So they are not willing to follow through the anti-GAK design process
where this could hinder bottom lines.

Similar arguments would presumably present them with "no choice" but
to fulfill the order for 100,000 GAK compliant units from the
government terrorizing the freedom fighters PRZ likes to tell us
about who are already using PGP GAK compliant software: pgp5.0.

Tim May <tcmay@got.net> writes:
> let me throw out some examples where CMR introduces flaws into a
> security system.
> 
> [snip]

I think Tim's points are very valid.  CMR functionality if put into
the OpenPGP standard _will_ be used by PGP competitors to implement
message screening and snooping by company security guards etc.  It
will I am almost positive in due course be used to field such software
in countries with poor civil rights records.

Maybe PGP is not fielding systems they are "advising" their clients to
use for GAK, or for message screening, but this is what is going to
happen.  Their good advice isn't as much comfort as an OpenPGP
standard which is as hostile to this practice as possible, and a pgp
data recovery implementation which is also hostile to this.

PGP do not want to hear this.  It will cost development time.

The many people who have expressed to me off list that PGP has sold
out, are I think correct.

> Which means we're back to square one. So why does PGP, Inc. bother?
> 
> And why should OpenPGP squander efforts worrying about this?

I think that except for carefully worded statements by PGP Inc
employees all those who have spoken on the topic in the OpenPGP forum
have agreed.  The CMR field should not go in OpenPGP.  This means that
the PGP SMTP policy enforcer will not meet the OpenPGP standard: it
will bounce mail from compliant implementations which ignore the CMR
field.

I think this means that the person who suggested this:

	OpenPGP is unlikely to continue to be supported by PGP Inc

to me in email made a good prediction.


What can we do about this situation?  Well we could build systems
which hack around the CMR system.  Easy enough: just put dud
"recovery" info inside.  We still have deployment problems.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`






Thread