[726] in cryptography@c2.net mail archive
Re: Full Strength Stronghold 2.0 Released Worldwide
daemon@ATHENA.MIT.EDU (Matt Blaze)
Wed May 7 15:27:44 1997
To: Tom Weinstein <tomw@netscape.com>
cc: Adam Shostack <adam@homeport.org>, cryptography@c2.net
In-reply-to: Your message of "Tue, 06 May 1997 09:00:04 PDT."
<336F5584.2781@netscape.com>
Date: Wed, 07 May 1997 09:39:01 -0400
From: Matt Blaze <mab@crypto.com>
> Adam Shostack wrote:
> >
> > I agree with Sameer here. What is the requirement being served by
> > KR/OKAY in Netscape's system?
> >
> > Adam
> >
> > (I also like Sameer's use of KR/OKAY and KR/GAK to indicate how close
> > they are to each other. Mandated OKAY features can be turned into
> > GAK. Better to let the market decide which KR features are needed,
> > and how to implement them.)
>
> My previous use of a recovering from loss of a server key was a bad
> example. We don't actually intend our KR solution to include server
> keys. Those will be recoverable from backups of the key database or
> from our key import/export mechanism.
>
> The real purpose of KR is for recovering keys for encrypted email.
>
> This is a market driven requirement. We've had numerous meetings with
> customers trying to figure out what their requirements are. The most
> requested thing has been key recovery. Administrators are scared to
> death that as soon as their users start sending encrypted email all
> hell will break loose. They need a way to recover from lost keys and
> forgotten password.
Market driven? I'm not sure I understand; it's not clear what the "market"
is asking for here.
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.
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).
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.
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.
-matt
