[837] in cryptography@c2.net mail archive
Re: forward secrecy and email protocols
daemon@ATHENA.MIT.EDU (Bill Stewart)
Thu May 15 12:53:26 1997
Date: Thu, 15 May 1997 01:29:45 -0700
To: Adam Back <aba@dcs.ex.ac.uk>
From: Bill Stewart <stewarts@ix.netcom.com>
Cc: cryptography@c2.net
In-Reply-To: <199705091315.OAA02228@server.test.net>
At 02:15 PM 5/9/97 +0100, Adam Back wrote:
>No existing email communications systems I am aware of have forward
>secrecy, because to take PGP as an example: the eavesdropper has
>escrowed your ciphertext, and you still have the private key.
...
>The problem is how do we easily integrate this into existing mail
>protocols, which are non-interactive. If we modify SMTP to do D-H key
>exchange, we have shifted the security from keys held by the user, to
>keys held by the SMTP daemon.
>
>I'm not sure non-interactive forward secrecy protocols are possible.
Diffie-Hellman is the popular forward secrecy protocol;
I'm not sure if there's a non-interactive approach.
But you could build interactivity into a mail system,
at the cost of some annoyance. However, even the forward secrecy
of DH requires that you discard your private keypart
after use; you can trade some security for efficiency
be reusing the keypart for multiple transactions.
If you ran your own SMTP daemon as a user, you could avoid the problem,
but most mail users don't work that way; a shared mail server and
POP, or IMAP, or delivery to a mailbox is much more common,
and easier to keep working.
You could build a mail responder to hand out DH keyparts,
with the DH exchange requiring messages between clients.
This requires that your mail client be online to avoid delivery delays.
Alternatively, you could modify both the client and the SMTP server
so that the client hands the server a DH public keypart to use for
incoming mail. The obvious implementation will use the same DH
keypart for a whole batch of mail, which is probably not a bad tradeoff
for forward secrecy. Another approach, giving the server a batch of
use-once keys, is susceptible to the denial of service attack
Adam referred to.
The sender's end has a different set of tradeoffs.
Either it can perform the SMTP sending end itself (rather than
using an SMTP forwarding server, which most mail clients use)
or else trust the forwarding server with its private keypart,
which is risky. On the other hand, if the recipient's SMTP server
is active at a major ISP, it'd be easy to find and you probably won't
have to wait a long time for the server to answer, which are
the main things sendmail really does these days (:-)
Alternatively, you could separate the key handling from the
mail system and just use a keyserver. There are problems with this
approach as well. After sending a public keypart to someone,
how long is it safe to keep the private keypart around?
Do you need expiration dates on DH public keyparts?
How long do you keep the private keypart around after the
public keypart expires to accommodate mail delays?
# Thanks; Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
# (If this is a mailing list, please Cc: me on replies. Thanks.)
