[740] in cryptography@c2.net mail archive
Re: Full Strength Stronghold 2.0 Released Worldwide
daemon@ATHENA.MIT.EDU (Matt Blaze)
Wed May 7 20:17:37 1997
To: Tom Weinstein <tomw@netscape.com>
cc: Adam Shostack <adam@homeport.org>, cryptography@c2.net
In-reply-to: Your message of "Wed, 07 May 1997 10:16:18 PDT."
<3370B8E2.794B@netscape.com>
Date: Wed, 07 May 1997 13:38:53 -0400
From: Matt Blaze <mab@crypto.com>
> >> 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.
> >
> > Isn't that what certificates and a key distribution system are for?
>
> What? If you send encrypted mail to me but I lose my key before the
> mail arrives, how do I read the message? I can either get you to send
> the message again using a new key (which may not be possible), or have
> my key recovered. It may be acceptable in some cases to say that the
> mail is lost. It is certainly not acceptable in all cases.
I don't buy this at all as a reason for including (or even designing)
a mechanism to recover secret components of certified public keys. There's
already a scheme to deal with the problem of ensuring that the sender
uses the correct public key: certification (and certificate distribution).
That's the place to solve this problem. True, there may be a race condition
here, but it's surely no worse than the general reliability of any of the
Internet email protocols (which allow bouncing and even dropping messages
under many circumstances, several of which are far more common than lost
keys - full spool disks and, sometimes, un-resolvable names, for example).
While it may be possible to imagine some mission-critical applications that
can't tolerate this unusual race condition, I can't see how this special case
justifies such a problematic (from a security point of view) design in general
(problematic even for users who want this feature).
I'm more sympathetic to your argument about users of IMAP servers, but perhaps
a better solution is to redeliver the message back to the user, encrypted
with a new (secret) key. Perhaps its reasonable to simply specify that
messages still in the server are "in transit" and therefore not recoverable,
or to provide a scheme for THOSE users to recover their keys. I'm not
familiar with the details of IMAP, however, so I defer to others for how this
might be
addressed, but it sounds like the issue of how encryption interacts with
things like IMAP/POP needs to be re-thought, and perhaps those protocols
extended or redesigned.
Anyway, any key recovery mechanism adds so much complexity to the system that,
at a minimum, alternatives should be carefully explored first. Indeed,
I suspect that in most applications these mechanisms reduce security far
more than they help assure availability.
-matt
