[796] in cryptography@c2.net mail archive
Re: forward secrecy and email protocols
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Sun May 11 12:49:43 1997
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: aba@dcs.ex.ac.uk, cryptography@c2.net
Reply-To: pgut001@cs.auckland.ac.nz
X-Charge-To: pgut001
Date: Sun, 11 May 1997 13:21:59 (NZST)
Adam Back <aba@dcs.ex.ac.uk> writes:
>Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:
>>Why not bolt something like SKEME over the top of SMTP? This gives
>>perfect forward secrecy and authentication (and has several other
>>neat features as well, depending on your requirements).
>SKEME's keys are for link security rather than object or message security.
>If you used SKEME directly you could get forward secrecy, but the keys
>wouldn't be owned by the user.
That should be enough for bolt-on security for most people. Assuming the
communication is between mail hubs, each hub distributes (say) a PGP key to
remote hubs which they're likely to communicate with[1], and uses this to
establish a SKEME session. For example if I wanted to send mail to you I'd
use the key for dcs.ex.ac.uk (or whatever your mail host is) and you'd use
the one for cs.auckland.ac.nz. This protects the link (which is where any
interception is going to occur, if someone's compromised your local machine
then no amount of encryption will help), and can be bolted over the top of
whatever MTA you use (sendmail, qmail, whatever). Having the private key used
for authentication stored in memory is a small risk, but it can reasonably be
assumed that the mail hub is vaguely secure, and in any case the only thing a
compromise will give an attacker is the ability to perform a MITM attack on
the DH exchange.
>Using link level security where your SMTP session was transparently tunneled
>through an encrypted IP layer with forward secrecy would give you this
>transparently.
The problem is that encrypted IP layers are kind of scarce at the moment, and
will probably continue to be so for awhile, especially if you're outside the
US and need to rely on US vendors for your software. The bolt-on approach
means you can add security to existing setups without too much trouble (just
hack your sendmail config to go via some sort of local proxy which sets up the
SKEME session with the remote host a la the various SSL proxies floating
around).
>Email for many users is store and forward with SMTP mail hubs and POP3
>accounts. This class of users does not have the ability to have a
>permanently connected IP addresses hosting with a SKEME key management
>process running.
You don't need direct connectivity, since security is taken care of by the
mail hubs (in fact direct connectivity is a problem for the majority of users
who'll be on Wintel boxes, which aren't amenable to sendmail hacks).
>So perhaps you could hive off distribution of sets of short-lived keys to a
>keyserver, or the ISP. Say we distribute one weeks keys at a time, one key
>per day, delete keys a day after expiry. Or have use-once keys as in DMS.
>Disadvantage for dial-up users is you've got to go online and fetch an
>up-to-date key for the recipient before posting. For people with permanent
>connectivity (say corporates) this will be less of a problem.
Key compromise isn't *really* such a big problem since it's only used for
authentication, and SKEME allows for anonymous transfers by encrypting ID's.
If necessary though the SKEME process running on the hub could refresh keys as
required. Would it really be necessary to switch authentication keys this
often? Breaking into a mail hub, stealing an in-memory key, and then
performing a MITM attack on the SKEME session is a fairly nontrivial task.
Peter.
[1] This description of events hides a lot of detail.
