Re: Encrypted SMTP (was Re: wish list)

[Ron Arts <raarts@netland.nl>]

Ray Jones wrote:
> 
> -----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.
> 

According to my experience with HTTP servers (I am responsible for over
a thousand)
HTTPS request are at least 10 times as CPU intensive as normal requests. 
This is a pretty well known fact among SSL users and experts. 

Tests have shown that webservers that could normally handle tens to
hundreds 
of requests per second bogged down to as low as three per second when 
everything went through the SSL port.

It has gotten to the point where several suppliers are offering
dedicated
hardware to decrypt SSL traffic on secure servers.

Raj's estimate sounds reasonable to me.

> > 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.
> 

If all SMTP sessions in the world would be SSL, then the amount
of installed CPU power would definitely need to rise a lot....

> > 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

Yes, there is. An ESMTP mailserver indicates it is SSL capable, and then
the client can then ask the server to start an SSL handshake on their
session.

I haven't seen a sendmail implementation of this, but I think I saw one
for 
Wietse Venema's new mailer that was adapted by IBM.

Ron Arts

> > 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/
-
Securedistros: A common list for all secured Linux distributions
Archive:       http://humbolt.nl.linux.org/lists/