Re: do NOT escrow communications keys

[Anonymous <nobody@REPLAY.COM>]

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.

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.  Schneier means the same thing with regard to "data backup".

> (forward secrecy)

This could be a good idea, particularly in terms of old keys leaking
out, but it needs more work.  It's not clear that any of the forward
secrecy methods will work for email.  You can't easily do a DH key
exchange via email because of the multiple messages.  Maybe you could
piggyback on ordinary messages, and after a few have been exchanged,
you can get a DH key for the next message, but this is very complicated.
Synchronization isn't guaranteed with email, neither is reliable delivery.

> (untransferable signatures)

This is also a good idea, but it needs more work, too.  There is a big
education problem here.  People barely understand the implications of
regular digital signatures.  Now you are throwing this new kind in, which
guarantee the message came from another person, but aren't binding.  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?

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.

There may be patents on these technologies, too.

> (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.  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.
If he forgets, the business owner has lost access.  There will be
extra training costs, and people will have to change their habits.
Besides being more complex to design and implement, it will be harder
to sell to customers.