From: Adam Back <aba@dcs.ex.ac.uk>
Date: Tue, 14 Oct 1997 03:35:32 +0800
To: nobody@REPLAY.COM
Subject: Re: Auto-archiving cleartext is GAK
In-Reply-To: <199710130335.FAA19075@basement.replay.com>
Message-ID: <199710131924.UAA02724@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Anonymous gives some more good feed back on the PGP GAK argument.  A
real battle of wits here, anonymous appears to be a pro, probably a
PGP employee, anonymous doesn't miss anything (apart from the fact
that he has apparently swallowed whole the "communications key
recovery" fallacy being spread by the GAKkers).

Anonymous writes:
> Advocates of the model where software is automatically archived on
> receipt, either in cleartext or re-encrypted with a corporate key,
> need to be aware that there are problems with it:
> 
> No notification to sender about the policy.
> 
> [..]  People should know if their mail is going to be automatically
> saved in the clear to a company archive.  The best way to make sure
> of that is to have the sender be the one to do it, or not.

Hmm, you've turned that argument on it's head there, and come up with
an interesting counter point.

I'm not sure it's that valuable a distinction though, because you
can't enforce it either way.  You really have no idea what the
recipients software is doing, nor who the recipient is printing out
and showing your email to.

I think that the best that can be hoped for is that it is considered
fair play, and a convention that businesses are encouraged to adopt,
that second reader policy, and storage policy is flagged.

Following from your concerns it would seem we currently have 3
possible "how I treat email" flags:

- email is readable by company
- email is being archived for company records
- email is being archived in the clear
- email is discarded after reading

Interestingly pgp 2.x has an option to partially suggest that last
one, a kind of "don't save in clear" request (from pgp.hlp in pgp263i):

Use -m to force display of plaintext only (no output file)

I know one person who used to regularly send me stuff encrypted this
way -- it used to cause my mail client to barf (emacs RMAIL &
mailcrypt.el) because it couldn't cope with this, so I had to manually
read it with the command line pgp, which would insist on displaying it
to you with it's pager, and not storing it to file.

Quite a nice privacy touch.


Anyway you used your point to argue that:

> The best way to make sure of that is to have the sender be the one
> to do it, or not.

which I take to mean that you are using that to argue that the PGP
GAKware enforcement feature is a good idea.

I strongly disagree because a) communications keys should be shorter
lived than storage keys, b) the way the PGP GAKware enforcement and
flags are implemented is literally an full GAK implementation, c) that
it is less secure to put extra doors into what should be for security
reasons short lived keys.

> No way to prevent third-party access.
> 
> With the corporate message recovery feature, the sender has the
> option of simply ignoring the recovery key and sending it encrypted just
> to the recipient.  Some corporations won't let it through, others will.

True.

> Some companies will want mail to be made recoverable by default, while
> still allowing an escape clause for personal mail and special purposes
> (like for "sensitive" mail which needs protection against subpoena
> and discovery).  They can use the "optional" CMR mode.  Again, senders
> are always notified as to which mode is being used by a given company,

Notifying senders of the archiving and access policy is good and to be
encouraged, however it never proves anything about what is actually
happening to your email, nor can it.

> and senders can be confident that if they don't use the third-party key,
> no access will be possible.  

I don't think this is true.  They will have no more proof that this is
the case than they will have with the storage recovery key solution.
Consider: the company could just as easily take copies of the email
after the user decrypts it with CMR.

The user may have an _expectation_ that there is no third party
access, but they can only hope that their expectation tallies with the
truth of the situation, and this is the case for either my storage
recovery solution, or PGP's CMR solution.

So there are no meaningful differences from this angle.

There are two major and definately meaningful differences between
corporate storage recovery (CSR) and CMR:

- CMR is a fully functional GAK implementation CSR is not

  This is directly analogous to the difference between GAK and data
  recovery, and was the reason the cypherpunks that Jon Callas
  observed chanting "key recovery bad data recovery good" where
  chanting.  The irony was Jon didn't realise that he was falling for
  the GAKker promulgated fallacy that these cypherpunks were chanting
  against, and yet he was using the same chant in his arguments not
  realising what it meant.

- CSR is more secure because:
  a) it allows shorter lived communications keys
  b) because it leaves no long term doors into communications, whereas
     CMR leaves two doors into communications

> With automatic encryption and archival on receipt, all mail will be
> archived, and senders have no notice and no guarantee that stated
> policies will be followed.

You have no guarantees either way.  You can implement any
functionality for storage, escrow, and message snooping with varying
loose degrees of tamper resistance into either CSR or CMR, using a
combination of storage key escrow (CSR) and Mail client enforcement or
GAKware (CMR) with the session key going over the wire encrypted to
the GAK master key.

As I said above, the best we can do is to encourage truth in
advertising about storage policy and number of people who can read;
and to provide flags to express these meanings within the OpenPGP
standard.

> No escape via super-encryption.
> 
> Even if the company is mandating a recovery key and filtering out
> messages which aren't encrypted to it, the sender still has the option to
> super-encrypt with the recipient key alone, before sending the message
> encrypted to the corporate recovery key.  This ensures that only the
> recipient's personal key can read the message.  With software which
> automatically saves the cleartext of the message, once the user reads
> the data it is available to the corporation via the snoopware.

Wew.  Hadn't thought of it that way.  Well you could choose to
implement it that way, or you chose not to at your option.  It hadn't
even entered my head to implement it that way! and I would strongly
argue against so doing.  (I am starting to appreciate how PGP people
must feel about my criticisms of their features; never-the-less, I am
confident that my argument is correct, and it is they who have allowed
themselves to be blinded by the GAKkers fallacy of escrowing
communications keys (the chanting cypherpunks mantra explained above)).

However, and this shows how you can still trivially hack around it,
you could super encrypt to a key which wasn't storage escrowed.

I also have said things about "official email" and "unofficial email"
which I considered companies should be encouraged to provide for their
employees, and there is a case to be made for this as argued by Tim
May and Bill Frantz recently, which is that it is probably not in the
companies interests.

I originally started out thinking that companies didn't as such need
much in the way of access to old email messages, or that they could
store them in the clear and encrypt the whole disk with recoverable
storage keys.  However some tenacious people (you?) started arguing
that it would be a security breach to store email in the clear after
having encrypted it for communications.  There is also the case to
consider of the PGP Inc mail client which does not integrate disk
storage functionality.

Therefore I was worked out a sample architecture demonstrating that
you could archive email in encrytped form if you wanted to acheive
this without needing GAK compliant architectures such as CMR.

I would also defend myself from the above slur that I was trying extra
hard to ensure that there is no escape from super encryption.

I have lots of ammunition, don't worry :-)

The reason that I am trying to demonstrate that you can enforce any of
this at all, is that some of the GAKware proponents on the list
(anonymous and not) argue that it is necessary not just to have access
to communications keys for data recovery purposes to ensure data
availability (there's that recurring fallacy again), but also that it
should be possible for the company to snoop on the user without the
user being able to avoid this.

If you are at all worried that your GAKware CMR system doesn't quite
meet up with the flexibility of my system in allowing you to get all
little brotherish and enforce things, well I can make a suggestion as
to how to increase the enforcement rate of your GAKware system.

Do a web search on "Binding Cryptography" by a guy called Bert-Jaap
Koops, and a couple of co-authors (I think another of the authors is
the main author, but I don't remember their names right now.)  I was
particularly disappointed at the time with Bert-Jaap for allowing his
name to be put on a paper describing a technology which has only one
purpose: GAK enforcement, and expressed this to him.  However I
suppose technology is neutral -- it is what you use it for that is the
problem, probably it could have some other uses.

So, y'all PGP Inc GAK lovers will love what this allows: it allows you
to enforce at your GAKware big brotherish SMTP policy enforcer app on
the inbound direction that not only is the El Gamal key with the
correct key-id there in the GAK master key second recipient, but that
the same session key is in use inside of the users PKE packet.

Not that I'm suggesting that you do that or anything, I merely draw it
to your attention to demonstrate my point that either of the systems
can be implemented in varying amounts little brotherishness, but that
the over-riding point still remains that CMR is a fully functional GAK
system where-as CSR is functionally useless for GAKkers because they
want to read your communications, not what is stored on your disk.

This is because the GAKkers will have to break in to your building to
get your disk, this is not nearly enough fun for the Feds, because
they kind of fancied having push button remote key word scans of the
entire world communications.

(Remember the meme the chanting cypherpunks were trying to promulgate
as described above: governments want access to comms keys, businesses
want access to storage keys.  This cypherpunks meme is absolutely
central to the whole argument).

> Facilitates GAK!
> 
> Suppose this solution is adopted, and software is developed which
> automatically re-encrypts received email and sends it to a secure archive.
> It's robust and works with a wide variety of email packages.  Now the
> government could simply mandate this to be used for all mail reading
> software.  

You are indeed an observant anonymous person!  I'm obviously dealing
with an extremely bright person, even if he seems to have swallowed
the inherent fallacy of the communications "key recovery" meme which
the GAKkers are promulgating.

I too fretted over this possibility.  And this is why I tried to avoid
the idea that you would have a central company archive of stored
encrypted email.  I couldn't work out a way to ensure that the
communications which were intended to occur inside the corporate LAN
could be prevented from being abused to implement GAK, a problem that
you so observantly spotted also.

Aside from being awkward and implementing it with screwy transfer
protocols so that it was all non-standard, it seems inherently
difficult to avoid.

So firstly I switched to contenting myself with satisfying what PGP
Inc claimed the user requirements for CMR where.  To me this meant
that centralised backup would have to be avoided to avoid GAK
compliance.  You could argue independently that not doing this is far
less little brotherish anyway.  Also that you can enforce to some
reasonable degree storage on the local machine, to give second access
to the users mail folder, which is better than having a central
snoopware HQ, which can then be perverted to become NSA GAKware HQ.
(Granted the employee could purposely trash the disk by taking it out
and breaking it -- but you'd still have backups from the last backup
point -- and we're not after 100% success rate because there are other
easier ways to bypass the system).

Jon Callas claimed the main company requirement for data recovery was
for companies to be able to retain data availability.  So if we take
him at face value, that presumably means that companies don't
especially want high assurance snoop functionality to read email where
recipients refuse to decrypt it, or go to extra efforts like
super-encryption.  Jon Callas and other PGP employees also argued as a
plus point for the CMR design that it was easy to bypass.  This
suggested that users could deny company data availability in a number
of ways, and that PGP employees wouldn't be losing sleep over that.

Well CSR achieves all that.  You can hack it in various basically
analogous ways that you can hack CMR.

Now, as I describe above, the reason that I started talking about
tamper proof clients was to demonstrate to those who complained of
loss of company ability to snoop in the face of a company employee
hostile to the snooping.  If you don't like that (and I sure as fuck
don't), well don't build the little brotherism in either.

But, if you do want to have some kind of mildly enforceable corporate
snoopware well you can do it with reencryption to an escrowed storage
key or to a key recovery storage key.

For people who want to stop employees beyond that I think it is
reasonable to say that this is disproportionate effort spent on the
problem given other physical avenues for company information leaks.

If a company is that way inclined that could say that attempts to
subvert the snoopware was a sackable offense.  (Again not that I'm
arguing we should be encouraging companies to do any of these things,
but rather than in proposing the CSR method as a non GAK compliant
replacemnt for CMR, I am being challenged to demonstrate it can do
everything that CSR can do with similar levels of enforceability).

> The secure archive would be a remote archive maintained by the FBI
> to protect public safety.  All plaintext would be sent there,
> encrypted by the FBI key.  The business software would already
> support this.  This is GAKware!  Unlike with a CMR system, the
> sender would have no way to prevent access.

He could prevent as I argued above; also you could build more secure
and similarly hard to bypass GAKware (CMRware) with Binding
Cryptography and a restriction to El Gamal keys.  Anway I would
strongly argue against fielding a system which worked in this way, for
the exact same reasons that I am arguing against PGP Inc's fielding of
the CMR system: because as you so rightly and observantly point out it
is GAK.  (I am not noticing you say much about CMR being GAK
... perhaps you actually acknowledge it is GAK, but are trying (and I
think failing) to show that CSR is GAK too.  Well no dice, I think CSR
allows non GAK compliant functionality with a large degree of
flexibility.  CMR on the other hand just _is_ GAKware.  If you
remember the KRAP (Key Recovery Alliance Program) and have the
documents handy I am sure that if you go down the checklist that you
will find that pgp5.5 matches just about all of the hotly contested
NSA given requirments.

> Can't handle forgotten passphrases.
> 
> People forget passphrases all the time.  With re-encryption on receipt,
> there is no way to recover gracefully from this error.  All the incoming
> encrypted data is lost until you can notify everyone who has sent mail to
> resend it, and get your new key out to all of them.  These may be purchase
> orders, sales leads and other important documents which represent lost
> business if they can't be recovered.  This is going to invite people to
> use poor security practices like writing down passphrases or choosing
> ones which are easy to guess.  Worse, it...

Lets think this through.  You have 3 keys.

- storage keys
- signature keys
- communications keys

You can escrow storage keys if you want -- this provides data
availability.  As an alternate and approximately equivalent mechanism
you can use storage key recovery (with a second storage recipient).

Signature keys we shouldn't have any arguments about I think because
y'all presumably agree that the user should be the only hodler of
those to prevent third parties forging his signature.

Communications keys, for security, and non-GAK compliant design
reasons you also should not escrow.

I think that your complaint is the same as that raised by someone
else, that is if some emails come in and in the mean time the employee
forgets his passphrase, you lose the emails because you can't recover
the communications key, because it is treated like signature keys; no
escrow, no backup.

This is a valid complaint.

However as a fob to the significance of this I can offer:

- if the email is important value "official communications" as you
  suggest, it might be an idea for the sender to archive them anyway
  in case they disappear down a blackhole in transit, or it will be
  independently likely that the important company document / figures /
  source code will be stored on the senders disk somewhere.

It's the only down side I can see for the system, which allows you to
avoid GAK compliancy.  It also has a number of quite major security
advantages which I discussed with William Geiger in the thread on DH
forward secrecy in email.

> Invites key escrow.
> 
> In order to prevent this problem, employees may be forced to share
> their secret keys with corporate management.  

You could do this as a solution.  However it has GAK problems, and has
as you say Clipper overtones, using the same master access method.

However you could also view it this way: you will likely be encrypting
the private parts of the communications key with the same passphrase
as the private parts of the signature key.  If the user forgets their
signature passphrase you'll have to issue them with a new set of
certificates for their newly generated signature key.  This is also
inconvenient, but you live with it because of the over-riding
principle that signature keys should only be held by individuals.

With communications keys the main reason not to escrow them is that
doing so builds a GAK system.  Thus is harder to argue that these
restrictions are inherently necessary unless you want to avoid GAK so
much that you are willing to live with this weakness.

I'll think on this part to see if I can find some way to tune down the
significance of this type of data loss.  Do you have any ideas?

One which comes to mind is smart cards for key tokens.  Harder to
forget.  Still you _can_ lose them.

There is however a separate danger with smart cards, they are kind of
a form of escrow themselves if they are not tamper-proof enough
because someone with resources may be able to recover the keys from
them.

Smart cards are however very convenient for key storage.

> Software will be written to facilitate this process.  Crypto
> companies are already doing this.  Nortel Entrust allows key
> generation by management, where employees are given the keys and
> management keeps a copy.  Shades of Clipper!  This also fails the
> notification requirement.  Don't believe me?  Take a look at this
> description of the Nortel Entrust product:

Yeah I believe you.  Some folks don't give a shit about privacy, nor
about GAK.  The $ is all that counts to them.  Selling their mother
for a bit of change wouldn't cause them a second thought.

> No system is ideal.
> 
> Before pushing this re-encryption model as a panacea, think about the
> implications.  No system which provides automatic access to business data
> is going to be privacy friendly.  Any such system can be perverted into
> supporting GAK.  Load it up with all the disclaimers you like, but if
> you advocate software which contains key escrow and which automatically
> provides cleartext to third parties, you are not advocating software
> which protects privacy.  Be prepared to be called an advocate of GAK next
> time you push for software which automatically archives cleartext, because
> if it can save it for business, it can save it for government.

The difference is still centered around the central fallacy that the
GAKkers are promulgating that the government should be allowed to have
access to all of your communication keys to allow the company to
protect data availibility.

The problem is that your disk is not stored in those communications,
so having the communications key back from the government key recovery
infrastructure does nothing to help you recover your disk data in
event of a disk crash.

In addition my simple observations derived from this are that well:

- if government is so damn keen on gaining access to communications
  keys, we'd better make damn sure we have no data on disk encrypted
  with communications keys!

- if government is so damn keen on encouraging companies to build GAK
  products (clipper, tessera, KRAP (Key Recovery Alliance Program)
  Public Key Infrastructure ("CAs" with copies of communications keys,
  as if you want them backed up)), well I'm going to do my damnest to
  make sure that I don't write the software.  If PGP Inc chooses not
  to write a GAK compliant product, and the PGP standard is
  successful, well then we have done all we can to frustrate
  government GAK plans

Given those observations, lets take a look at this claim:

> No system is ideal.
> 
> Before pushing this re-encryption model as a panacea, think about the
> implications.  

I'm trying.  Your feed back is helping to explore the limitations and
flexibilites of CSR as new scenarios are explored.

> No system which provides automatic access to business data is going
> to be privacy friendly.  

Well it's a little brotherish sort of activity perhaps, but some argue
that companies have property rights which you could use to conclude
that if they are paying for your time, and they own the machines, and
the networking facilities, that perhaps this isn't so unreasonable.

Provided you stick to data stored on disks you minimise your problems
of being accuesed of GAK.

> Any such system can be perverted into supporting GAK.

I have given you a CSR architecture which is non GAK compliant.  Your
task is to deploy this as widely as you can.  Then with 80% of
companies using non GAK compliant software, the GAKkers are going to
be struggling.

The other scenario, PGP Inc's CMR, is already GAK enabled.  It
provides a smooth migration path to GAK.  With 80% of companies using
that type of GAK compliant software we're screwed.  PGP will be the
guilty party.

> Load it up with all the disclaimers you like, but if you advocate
> software which contains key escrow and which automatically provides
> cleartext to third parties, you are not advocating software which
> protects privacy.

There can be legitimate reasons for restrictions on privacy within
companies where this is required to ensure data availability.  The
main points about this are that a) you recommend the policy of
informing users (ensuring that they know that the data on this disk is
backed up, that this email folder is backed up etc.) b) that PGP
doesn't use the excuse that a GAK system _could_ be built by
perverting CSR as an excuse to fields something which is unavoidably a
GAK compliant system: CMR.  With CSR you as implementer and to a
certain extent standards setter have the power to do something about
having a non-GAK compliant installed software base.  With CMR you have
no choice but to implement and field GAK compliant software.

> Be prepared to be called an advocate of GAK next time you push for
> software which automatically archives cleartext, because if it can
> save it for business, it can save it for government.

I don't think that is really fair.  My motives for exploring the
functionalities is driven by other peoples user requirements which
they are thrusting on me with the challenge that I show that they can
be met with CSR.  I have almost completely been able to show that this
can be done for the things which have been thrust at me.

This in no way indicates that I _like_, or approve of the little
brotherish, or snoopy things people are challenging me to show can be
implemented with CSR.

But what I am certain of is that you _can_ build a non-GAK compliant
system with CSR, which can have just about any functionality you care
to add (snooping, weakly enforced email archiving to recoverable keys,
separate "official" and "unofficial" email boxes, flexible storage key
recovery architecture).

I am also certain that CMR as implemented by PGP is a fully
functioning ready to roll GAK compliant system.

Lets try a different tack: I'll issue _you_ a challenge: can you
modfiy the CMR proposal so that it still achieves stored email data
recovery and so that it is no longer GAK compliant.

I don't think you can do it.  I'll be happy to be proven wrong.

I think you'll find as you try to work your way around away from GAK
compliance it that you will end up with something which _is_ CSR.

Well?

(Thanks for the long debate... I hope it has been useful).

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`