From: Adam Back <aba@dcs.ex.ac.uk>
Date: Wed, 15 Oct 1997 06:58:44 +0800
To: smith@securecomputing.com
Subject: Re: proposal: commercial data recovery
In-Reply-To: <v03007804b0697514e0e4@[172.17.1.150]>
Message-ID: <199710142242.XAA08180@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Rick Smith <smith@securecomputing.com>
> Regarding the practical uses of e-mail key disclosure, let me include one
> from the guard/firewall world that I haven't seen mentioned yet:
> 
> We've been shipping products since 1994 that scan the contents of e-mail
> messages and reject contents that violate specified filtering criteria.
> Sites use it to block importation of viruses or other inappropriate
> attachments, and to block the export of improperly released information.
> Most of these systems have been sold to the government and use the Message
> Security Protocol to encrypt data. The system rejects messages that don't
> contain an extra key so that the firewall can scan message contents.

I'm not sure whether pgp5.5 has this ability to screen messages prior
to reading, and also not sure whether it has the ability to snoop
messages prior to sending built in.

The basis is there for the functionality in the enforced second
recipient, but I'm not sure whether the client, or SNMP management
tools, or SMTP policy enforcer implement this functionality.

I'd welcome clarification from PGP Inc., employees, or anyone in the
US has tried the pgp5.5 software for business suite.

> This violates the assumed requirement that the contents of an e-mail
> message must not be viewed by anyone except the message's author and
> recipient.

It does yes.  And that demonstrates that the principle is achieving
it's function in high-lighting areas of a design which could be used
for GAK purposes.

> However, it's a security trade-off that some organizations want to
> make for certain applications.

Absolutely.  You should try hard though to see if there are any
software hacks or protocol reorganisations you can do to make the
system unusable for GAK, or as close to unusable as you can.

> PGP's key recovery protocol isn't the perfect solution, but it would help
> resolve a big problem.

Where that problem is can messages be screen by processes?  One
solution if you restrict yourself to processes is to move the function
to the client and scan after decrypt.  This isn't as easy to integrate
into existing MUAs but would be possible for fresh re-writes like
pgp5.x clients.

If you want ability for humans to scan messages manually as well, and
you can't live with the modifications in the client, you can do this
within the CDR design principles:

Have all email received by the company encrypted to the companies
public key.  Have your virus filter/human screener check the email,
and then pass on to user in clear, or pass on to user encrypted with
users key.

Actually this is more secure than your solution, because the client
already has an in memory master key; and now you have one crypto
recipient rather than two to blow your security for you by allowing
inadvertent key compromise.

For outgoing email, configure the mail client plugin to either send in
plain-text, or to sign only (one hopes with non escrowed signature
keys, else your MIL friends will be able to forge each others mail),
or to encrypt to the outgoing filtering agent, and have the outbound
mail hub filter, or forward to human screener content checking.

CDR compliant.  Has some extra resistance to GAK corruption.

As an additional application of CDR anti-GAK principles you could do
the small software hack of allowing the clients and/or mail filtering
agents to only communicate with each other if the machine IP addresses
look like they are on the same mail hub.

Don't provide source.  (I suspect your company doesn't anyway for this
kind of app, or do MIL people like to inspect source?)

So now your system has a number of extra protections against being
used for GAK.  They are not perfect, but you've done what you can, and
it's a definate improvement over what you had before.


However I'm not sure it matters for your application really whether it
is GAK compliant or not.  This is because your application sounds like
it is mainly for defense contractors, and MIL or NSA type use.  As far
as I'm concerned that lot deserve GAK.  Keep themselves honest :-)

> To send mail through these systems, the users must be trained to
> include the firewalls as message recipients -- this produces a copy
> of the symmetric key encrypted with the firewalls' individual PKs.
> If a user forgets, then the message can not pass through. The PGP
> approach of warning or demanding another PK token would help solve
> that problem at least in simple cases.

You can acheive the same functionality by insisting on mail being
encrypted for the firewall.  Firewall can re-encrypt for intended
user.

> ObPolitics: Personally, I think it's too soon to tell if PGP's
> implementation would benefit the FBI in its pursuit of wiretapping keys. At
> most it might resolve whether such mechanisms are in fact a practical
> technology. I'm not yet convinced.

I think you have a point there and that it's not entirely clear how
this would work out.

> Also, if commercial sites have already co-opted PGP's recovery key for
> their own uses, it's not clear that the FBI will be able to use it for
> clandestine investigations. If they approach the site's IS managers to
> acquire copies of the firewall keys, there's a good chance a rumor will get
> back to the people being targeted for surveillance. 

I don't think that's the way it will work.  What they'll do is require
SEC cleared companies to provide this key as a matter of law to the
government.  If cheating is detected the bosses will get prison terms.
Then they'll slowly spread it from SEC cleared firms to other
companies.  Maybe Public companies.  Then they'll create a reichstag
fire FBI constructed publicity type cases; perhaps money laundering,
or purported mafia front business as an example of a public threat
from allowing companies to communicate without escrow.  Individuals
too, some terrorist cases, a few more large scale bombings.  No
problem.

If PGP provided facility for multiple enforced extra crypto
recipients, it would be even more GAK compliant, as companies could
just put a NSA key into the recipient box.


The CDR design principles also apply to standards.  Standards are very
powerful things.  If OpenPGP requires capability to understand and
encode to second crypto recipients which are not message recipients
for conformancy, we are in trouble also because all clients will then
be required to make GAK easier to enforce; the capability is right
there in pgp5.0 and pgp5.5 now.

If on the other hand the OpenPGP standard does not include the second
non message recipient crypto recipient feature, then companies who do
chose to do so must build up their own client base outside of the
installed client base, because they won't be able to build
GAK and have interoperability at the same time.

(We'll see whether or not PGP argue for this feature to go in the
standard in a bit, when the draft standard is released, and
discussions commence).

Also remember that another danger with GAK software is that your
country might be too liberal for the government to get away with
various things, but others aren't.

We don't want to encourage civil rights abuses.  In some countries
saying non-government approved thoughts results in prison terms,
torture, and painful death.

> Also, I believe the overhead for separate eavesdropping keys would
> produce too clear a sign to everyone that the FBI is
> listening. There is no precendent for such a thing and even if it's
> adopted temporarily I doubt it will persist. People will notice, it
> it will make them mad -- it will show them that the FBI is indeed
> under everyones' bed. Even the FBI can't stand up against broadly
> based grassroots pressure. Of course, I've been wrong before about
> politics.

Well I hope you're right of course, but I feel PGP could do more to
prevent the scenario I present above, which I feel is fairly
realistic.

I also hope I have provided some worked examples of the logic in
applying the CDR design principles.

(They are counter-intuitive sorts of principles to work with because
they are all negatives: don't do this, don't do that, no
recommendations as such on what _to do_.  This is because what you do
is explore the solution space outside of the restriction they apply on
it.  They are also strange in that it is unusual to see formally
codified cryptographic property design principles which reflect
entirely a political issue.  Must me a first :-)

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`