From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 19 Oct 1997 05:39:22 +0800
To: kent@bywater.songbird.com
Subject: jurisdictional interactions (Re: Is PGP still private?)
In-Reply-To: <19971018092636.45297@bywater.songbird.com>
Message-ID: <199710181905.UAA00883@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Kent Crispin <kent@bywater.songbird.com> writes:
> On Sat, Oct 18, 1997 at 08:48:56AM +0100, Adam Back wrote:
> > 
> > Jon Callas <jon@pgp.com> writes:
> [...]
> > 
> > My reasoning is this: as PGP Inc can not justify expense on such
> > developments, my CDR proposal would be much safer for them to
> > implement because it requires no steganography support, or other
> > privacy patches to provide protection against abuse of the software
> > for uses other than PGP Inc's designers intentions.
> 
> You keep talking as if your CDR proposal is other than vaporware.  So 
> far as I have seen you don't have a proposal, you have a wish.

I have described the CDR proposal in some detail, and have been able
to counter all arguments raised against it.

It is vaporware, but there are people who are offering to implement it
as an extension to systemics PGP capable library as a demonstrator for
the OpenPGP standardisation process to show how it would work in
practice.

You do have a point in that I should collect my arguments and write a
paper describing the tradeoffs.  I am in the process of doing this,
and will be interested in yours and others comments on this proposal.

> > However I simply posit that if you live in a scenario where everyone
> > you would like to communicate is forced to operate under your
> > combination: for example the local laws state all businesses and ISPs
> > insisting that they use pgp5.5 policy enforcer and turn on strict
> > flag.
> > 
> > This possibility seems to be being discounted as unrealistic, or at
> > least as being optional, because you can by pass it.
> 
> It does seem rather unrealistic.  It would essentially involve
> replacing the entire email infrastructure, at a significant cost, and
> a rather sweeping suite of further laws that restrict the use of
> encryption to only PGP, forbid me running sendmail on my linux box,
> etc, etc

I fail to follow your argument.  Could you explain further?  I am very
interested in discussion of the realism of scenarios for ways that GAK
might be enforced in various types of regimes examples being perhaps:

- Singapore hi-tech, but somewhat authoritarian government

- US, UK hi-tech, government interested in installing GAK (with
  euphamisms being used such as TTP (UK), "Key recovery"/"key escrow"
  (US)).

- Muslim countries, some oil rich, largely I think currently

- France with current position of no use of crypto without license
  (not typically availble), low enforcement rate (individuals use crypto
  with very low likelihood of prosecution), but more recent moves to
  allow unlicensed crypto which has mandatory access.

In what way does replacing the sendmail infrastructure have relevance?
You can always communicate in the clear so I am not claiming you can
not commmunicate, just that there are interesting interactions between
deployed software bases and different jurisdictions with different
legal restrictions on cryptography (ranging from none to weakly
enforced mandatory access, to heavily enforced mandatory access to ban
on cryptography).  If you consider this legal framework, the dynamics
of the ways that you can best estimate GAK will be introduced, and the
likelihood for each jurisidction, the enforcement rate, severity of
penalty for failure to comply, you have a very complex system. 

I would be interested to see comments on these issues, and what issues
this raises for protocol designers and software implementors.

My GAK resistant design principles attempt to provide useful rules of
thumb in making individual software systems, international standards,
and the distributed system formed of the deployed user base, and
enforcement rates, severities maximally resistant to GAK.

http://www.dcs.ex.ac.uk/~aba/grdesign/

My claim is that software implementations, and messaging standards
such as OpenPGP are not neutral in this process.  I think this is a
relatively obvious statement, which most would agree with.  I know
that PGP Inc has spent a lot of time considering alternatives on these
kinds of issues, and on privacy issues.

> > I can not see that being able to by pass it helps you in my scenario
> > if a) you will be detected when you do bypass it because the law
> > enforcers will discover they can't recover plaintext;
> 
> This implies a law against using any other form of crypto, period.  
> If such a law is passable the exemption for PGP's protocol will 
> really be immaterial.  That is, Yes, under an extremely draconian 
> regieme, extremely draconian things are possible.

There are regimes which would like to allow the government to read all
communications where it would not be practical to outlaw encryption
because many people can demonstrate a business case for it.

You live in one such regime: the US.  I live in another such regine:
the UK.

> > and b) you have
> > a "choice" of not being able to communicate with anyone, because in
> > practical terms you have a need to communicate. 
> 
> Implies that *all* other forms of communication have been outlawed.  
> Completely unrealistic.

It does not imply that at all.  If you presume that you wish to
communicate securely, faced with the above scenario, you are faced
with the choice I described: don't communicate at all, or communicate
insecurely.

> Adam, it is a complete and utter waste of time to debate this. 

Why?

I shall continue simply because I consider I have no moral
alternative, than to try to explore more GAK resistant variants of
CMR, or additions to CMR. Or to explore the CDR alternative approach
as a plausible alternative more resistant to GAK take over.

If you have any specific objections to my technical points, or
strategic analysis of usefulness of the two proposals in frustrating
government mass email snooping I would be interested to have you
discuss them.

> What would *not* be a waste of time would be more concrete proposals.  
> Whether PGP implements something is a separate question -- I would 
> like to get back to the question of designing a better email 
> encryption system.

That is a worth while endeavour independently.  However PGP Inc has
financial and implementational constraints (such as plugin APIs, and
so forth) which it naturally must work within.  Asking more than this
is not reasonable; these are the laws of gravity in the problem space.

To produce something which meets PGP Inc's design constraints seems
much more valuable to me than independent freeware or payware attempts
to explore alternative approaches simply because PGP is likely to have
the largest deployed base.  Increasing the resistance of PGP Inc's
systems by even a marginal amount is therefore automatically valuable.

> Your reencryption scheme fails because of the management of the short
> term encryption keys, among other things.  

I presume you are here referring to my suggestion that forward secrecy
would make the system more resistant to GAK take over.

PGP already has a mechanism to deal with short term encryption keys:
the expiry mechanism which has been available starting with pgp5.0.

The only novel suggestion relating to this is to reduce the expiry
period, to reduce exposure of keys.  This does not seem a radical
proposal.  It is independently a good security improvement.

Tim May has suggested that the simplest way to deal with the problems
of recovery is just to store the received email in clear text.

If PGP would like to enhance security of email archives by storing
them in encrypted then CDR is one practical way to do that.

> Here's another approach I will toss out, without thinking through:
> 
> How about formalizing superencryption, or tunneling? That is, treat
> CMR traffic as a transport medium for messages that are themselves
> already encrypted.  The "key" idea here is to allow layering of non
> CMR traffic over CMR traffic.  All the code for both is obviously
> already in PGP, with a little glue and perhaps some minor protocol
> mods...

This is a good suggestion.  It would be an improvement over allowing
CMR traffic to appear in the outer layer.  Jon Callas, Attila T Hun,
and Bill Stewart were discussing variations of this.  My suggestion
for forward secrecy could also be used in this way, and has similar
motivation, but is not necessarily end-to-end, as I gave specific
examples in my previous reply to you attempted to show.

A hybrid approach like this would be somewhere between the two systems
in resistance to government abuse.  It is a definate improvement.

Please don't give up on the debate as threatened above Kent;
constructive ideas like this are useful as they explore a wider
spectrum of properties in the proposed system variants.

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`