[739] in cryptography@c2.net mail archive
Re: Full Strength Stronghold 2.0 Released Worldwide
daemon@ATHENA.MIT.EDU (Tom Weinstein)
Wed May 7 20:16:49 1997
Date: Wed, 07 May 1997 09:37:29 -0700
From: Tom Weinstein <tomw@netscape.com>
To: Matt Blaze <mab@crypto.com>
CC: Adam Shostack <adam@homeport.org>, cryptography@c2.net
Matt Blaze wrote:
>
> Market driven? I'm not sure I understand; it's not clear what the
> "market" is asking for here.
Our customers don't want to lose their mail when they forget their
password. KR is one solution to this problem. There are certainly
others.
> It clearly makes no sense to want the ability to recover communication
> session keys (indeed, the ability to do so destroys forward secrecy,
> making communication protocols and implementations with a recovery
> feature much harder to secure or even evaluate). Equally clearly, it
> makes good sense in some applications to want the ability to recover
> keys for stored data.
Absolutely.
> Are the keys used to secure email communication session keys or stored
> data keys? The way we implement it today, both. This, I think, is a
> basic architectural weakness in the design of most secure email
> systems, including (especially) PGP. Some applications need to
> secure messages in transit, some need to secure stored messages, some
> need to secure both.
>
> A better design, I think, would upon receipt re-encrypt each message,
> if local storage security is needed, with a secret key, perhaps best
> relying on a general-purpose encrypting file system instead of the
> email system per-se. There is no reason to store the message in the
> (public-key) encrypted form with which it was protected in transit.
> "Key recovery" is an issue only for the local storage keys used to
> re-encrypt the messages to protect them long-term. (What about new
> messages sent to old public keys? It seems to me that preventing this
> problem is properly a function of the certification and key
> distribution subsystem, and in any case is no worse than the similar,
> and already existing, problem of new messages sent to old email
> addresses).
This is something we've thought about, but there are technical problems
with implementing it with today's technology. There are also schedule
problems with what we could do for this release.
The IMAP protocol allows long term storage of messages on the mail
server. You can create mail folders on the server, and even search
messages that live on the mail server and are only downloaded when you
want to read them. IMAP currently does not provide a way to download a
message, decrypt it, reencrypt it with a new key, and then upload it
back to the mail server. One solution would be to add such a mechanism
to IMAP.
One other problem is what to do about messages that are in transit when
the key is lost. It may not be acceptable to just discard those
messages, or ask them to be resent.
> There are many good reasons to separate email communication keys from
> email storage keys beyond the muddy key recovery issues. There are
> obvious performance issues (local file protection requires only
> secret-key techniques, which are, of course, much faster).
> Functionally, cleartext email storage allows the use of standard tools
> (I frequently grep my mailbox, but that doesn't work on any encrypted
> messages stored there). More importantly, key management is greatly
> simplified by separating these functions. The need to change public
> keys and the need to change local storage keys frequently occur at
> different times and for different reasons. The way current systems
> are designed, even if I change (and revoke or expire) my public key, I
> still have to keep the corresponding secret, forever, if I want to be
> able to continue to read old messages.
You assume that your mail is stored on your local disk. It may not be.
It might be stored in a mail server, or it might be stored on a network
file system. Other people may have access to your machine who you might
not want reading your mail.
> Interestingly, these arguments do not apply to signatures (but there's
> no "recovery" issue for signature keys anyway). Since it is
> frequently desirable to be able to convince a third party that a
> message was signed, the original signature applied by the sender has
> to be preserved on stored messages. So it isn't sufficient to simply
> strip off all of the in-transit security when storing a message.
> (Ideally, the certificate should also be saved, if we expect to need
> to be able to convince a third party.) I like to think of email
> signature as a higher-layer function of the mail user subsystem, while
> email encryption is a lower-layer function of the mail delivery
> subsystem (and also a (separate) function of the mail storage
> subsystem).
>
> In any case, it seems to me that we need to have a clear understanding
> of the properties and functions of different kinds of keys before we
> start talking about the need to "recover" them. Key recovery, by its
> nature, introduces a host of new problems that make the systems that
> use it less secure, more expensive, and harder to analyze, and so we
> need to be especially careful in selecting the keys that are exposed
> to these problems.
I agree completely. KR is only a valid solution for keys used for long
term storage and in many cases key backup is a better solution.
Our problem is that there are large organizations that want to use
secure mail. The administrators are held responsible for fixing things
when they break, even if it's the user's fault. The only practical way
that we've found to recover encrypted email in such a situation is KR.
--
You should only break rules of style if you can | Tom Weinstein
coherently explain what you gain by so doing. | tomw@netscape.com
