Encrypted SMTP (was Re: wish list)

[Ray Jones <rjones@pobox.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Raj Mathur <raju@sgi.com> writes:

> Uhm, sorry about the default VM message munging...
>
> Anyhow, I feel that it's more important to have user-level mail
> encryption rather than system- or connection-level encryption.  Not
> that the latter is not important!  However, the arguments are:
>
> 1.  System- and connection-level encryption is a massive load on the
> CPU.  If all (or most) of your SMTP connections are encrypted, which
> is presumably what we're aiming for, then your CPU will be doing
> nothing except handling 20 open SMTP connections at any given time.

It's not that massive, in my experience (limited, I admit).  Disk
access time seems to be more of the bottleneck, in most cases.

> 2.  The remote system has to support encrypted SMTP, and I don't know
> of too many servers around today which do.  I'm willing to be
> disabused of this notion in case it isn't true.

This is a chicken-and-egg problem.  If this isn't the place to start
moving towards such a system, I don't know where there would be one.
Besides, supporting it isn't the same as requiring it.

> 3.  Privacy issues still remain with encrypted connections, since
> finally the message reposes in a non-encrypted form on the target
> machines hard disk.

This is a significantly different threat model, one which is unrelated
to the one that encrypted SMTP tries to solve (eavesdropping).  The
argument is a strawman, anyway, since it can be fixed
straightforwardly by storing mail messages PKE'd for the user they are
addressed to.

> 4.  I haven't read the RFC (OK, you can flame me for that!), but
> presumably there's some way of switching between encrypted and
> unencrypted sessions between two servers which talk SSL SMTP.  In case
> there isn't, it's a waste of resources to send letters to your Mom
> encrypted (unless your Dad's name happens to be Kevin M ;-)

*Not using encrypted communication when it's available is almost
always the wrong thing.*  It gives the eavesdropper a strong hint that
they chould concentrate their resources on the encrypted
communication.  You've leaked a single bit of information, but it's
one with high value.  It's also an invitation to accidentally send
something in the clear when you meant to encrypt it.

> Keeping this in mind, I'd rather focus on user-level security,
> i.e. PGP, GnuPG or an equivalent.  There the user has the choice of
> whether to encrypt the message or not, and privacy is much much
> higher.  In other words, encrypt the payload and let the connection
> take care of itself.

These methods are less than optimal because they fail to hide as much
information as they should.  Mail headers are for the most part left
in the clear.  Traffic analysis is in many cases more important than
content analysis.  Fully encrypted exchanges are one step closer to
where you want to be.  (Mixmaster/Onion routing goes even further...)

Ray Jones
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.7 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE3XF2lY4NKW4VSSGARAmxiAJ45Y8p0+j6wkUZ6NGue9EH+N1dXQgCeOFWa
UO13nhlg/izezaPnA7ket88=
=1Ln4
-----END PGP SIGNATURE-----
-
Securedistros: A common list for all secured Linux distributions
Archive:       http://humbolt.nl.linux.org/lists/