Re: do NOT escrow communications keys

[Adam Back <aba@dcs.ex.ac.uk>]

Anonymous <nobody@replay.com> writes:
> Adam Back <aba@dcs.ex.ac.uk> writes:
> 
> > I'm arguing that you should not backup, or escrow communications keys,
> > and that you should backup storage keys.
> 
> Euphemism alert: when we are talking about the kind of data recovery
> we like, we call it "backup".  When we are talking about the kind we
> don't like, we call it "escrow".
> 
> Schneier did the same thing:
>
> Bruce Schneier:
> > Key escrow = someone other than the author or the intended recipient of the
> > message being able to decrypt it.
> >
> > There are valid reasons for data backup, but they have nothing to do with
> > crypto key recovery.

It's getting difficult to speak English around here, what with the
GAKkers redefining the terms and issuing updates to the NewSpeak
dictionary every month or so.

"escrow" already meant an object kept safe for one's own benefit.  Or
it did, until the GAKkers perverted it, and redefined it's meaning to
be backdoor for another person or organisations benefit
(government/spook benefit in their case).

Key recovery sounds like the process of using your backup plan to
recover keys.  You would think it means a plan to recover your keys in
case you have a hard disk crash or whatever.  Again for your own
benefit.  But no, with another new edition of the newspeak dictionary
it suddenly means backdoor, master key for government or other
organisation to access your communications.

(I also might admit to a small amount of hyperbole, "dastardly evil
government/spook/TLA master backdoor access" as compared to "backing
up your hard disk now and then is a good idea".  But hey, that's the
way I feel about it.)

> You don't actually mean that you should backup storage keys, you
> mean you should provide a means for someone other than the user to
> decrypt that stored data.  

Thank you.  With the obvious caveat that any given user may not want
this, but that if you are holding information for other people, that
is the information is other peoples valuable property, and the machine
belongs to that other person too, then you might find it useful to
give them a copy of the storage encryption key in case of disaster.
In fact if they are employing you, and the machine is theirs they
might reasonably insist upon it.  You clearly have the option not to
store your own private information on the machine.  In fact your
employee may have policies discouraging you from doing so.

> Schneier means the same thing with regard to "data backup".

The point about using the terms "data backup" and "data recovery", is
that it attempts to highlight the falacy of the fundamental
misconception buzzing around, as a result of the lastest issue of the
newspeak dictionary released from DC, that it is "essential and in
companies interests to be able to recover transient messages".  This
is bogus.  What is important is recovering DATA (using your backup
tapes to "recover" your data, when you have a disk crash).

Jon Callas' attempted invocation of the "key recovery bad" / "data
recovery good" mantra, was somewhat amusing in that he _was_ arguing
for data recovery, whilst implementing key recovery (or at least
transient communication message recovery).

> > (untransferable signatures)
> 
> What happens when an employee receives a message from a supplier
> signed with that kind of signature?  Can he make a decision on that
> basis, or not?

The legal beagles at your company will decide a policy for you
designed to minimise your companies chances of being sued over the
contents of your communications, and hence losing it's shareholders
money.

> In paper business correspondence, there is no such distinction.  A
> signed letter is transferable.  Go beyond this and business will be
> scratching its heads.  It's a solution looking for a problem.

No, it's a solution to a problem.  It's a solution to the problem that
Tim just explored in more detail, and one that I gave a few short
comments upon in one of my posts in this thread.

If your company can't be proven to have authored a document, it
reduces the value of that the document to an opponent doing attempting
to do creative legal work and create a headache for you company when
your archives are requested in a discovery process.

> There may be patents on these technologies, too.

Don't think so.  It's simple enough technology.

> > (re-encrypting email with an escrowed key for archival)
> 
> This is going to require special archival software and special actions on
> the part of users.

Yes it'll need special archival software; but you're providing an
integrated business solution right.  PGP Inc's (are you a PGP
employee?), already includes a number of components.  Key server, SMTP
policy enforcer, PGP for business.  

I might also point out that the current PGP for CAKware (pgp5.5)
solution also has the same problem.  Just because the message is
encrypted to a second recipient, is no guarantee that the user is
archiving it for you.

Say the user receives some email which is hot, hot, hot, and
immediately purges it from the received folder on eudora, or netscape,
or PGP for business.  So, now what good is your CAKware going to do
for you?  You don't have the message.  Therefore you have the same
problem if you wish to guarantee access to messages.

> You won't be able to do it as a transparent plugin.  The user can't
> save his mail the regular way (with some email packages), he has to
> remember to (also?) save it to the business access archive.  

Look, I'm not in favour of CAK, or GAK, or any other snoopy business,
PGP are the ones arguing for that.

What I'm proposing is that firstly you don't encourage people to do
it.  But, if you're convinced that people will shop elsewhere unless
you do provide archival facilities readable by the company, and
snooping facilities, I'm arguing that you ought to do it in such a way
that the resulting system isn't useful for _Government_ access to
keys.

So given that set of criteria I think it's entirely reasonable to say
to clients who demand encrypted user archival:

- You'll need new email clients on all your desks

And reasonable to tell clients who demand that the archive be central,
(to prevent users deleting archived messages that don't suit them)
that:

- You'll need to buy the LAN archive server module also

I also think it's entirely reasonable to tell clients who demand
snooping:

- you're little brotherish SOBs
- the client will send your LAN archiver a copy after the user has decrypted
- the client will send you a copy of sent email prior to encryption

So, to answer:

> If he forgets, the business owner has lost access.  

He won't forget: it will be integrated into pgp5.6 "for business for
people who don't like GAK" PGP mail clients.

> There will be extra training costs, and people will have to change
> their habits.  

Well they're going to have to learn how to use pgp5.6, but frankly
it's just as easy to use as pgp5.0 for personal security.

> Besides being more complex to design and implement, 

Oh come on, I think PGP Inc will be able to hack it.  Most of the
design I already worked out for them in the last few posts.

> it will be harder to sell to customers.

And there's the rub.  What comes first: profits, or selling out to the
US government.

I'm sorry, but I think PGP has sold out on this one.


You can justify most of the aspects of the system I outlined in terms
of security.  It is more secure.  Using forward secrecy is more secure
again, and imposes the same restrictions anyway.  You can therefore
use the line:

- you want to marginally easier to integrate snooping at the expense
  of security?

- what if your competitors also get to read your communications?

Also, might carry some weight:

- PGP is the standard solution, it doesn't work that way, for security
  reasons.  If you use competitors products which do work that way,
  you'll be unable to communicate with the rest of the world

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`