Re: Email Encryption

[Joe St Sauver <joe () OREGON UOREGON EDU>]

Kevin commented:

#We've been encouraged by an outside security firm to encrypt every blessed
#note that passes through our Exchange server.  This firm deals largely with
#entities such as banks, and I'm wondering if this is over-kill in the 
#context of higher ed.
#
#Any thoughts regarding "best practices" on this?

Rather than dismissing that recommendation out of hand, I'd take that
suggestion as an opportunity for a bit of internal reflection and 
discussion relating to possible options for encryption, or if not 
encryption, at least the facilitation of digital signatures for 
messages.

As pretty much everyone knows, email's currently woefully insecure (and
while things like SPF and DKIM have the potential to help, they're far
from a total solution).

In particular, anyone can spoof email that "looks" as if it came from 
anyone of interest. This can be hugely problematic, including enabling 
things like:

-- forged "class cancellations" and other malicious messages
-- potentially crippling levels of blowback from spam runs with forged 
   apparent senders
-- phishing via email
-- etc.

We also all know that even though folks are told not to, they will routinely
send information via email that really shouldn't be getting sent via an
unencrypted channel, or stored unencrypted in a plain text mail spool, 
such as FERPA-covered data, HIPAA-covered data, etc.

If folks *were* going to try increasing the adoption of email digital
signatures and encryption, there are various things that folks could try:

-- PGP/GNU Privacy Guard is the defacto default among technically inclined
   folks, although it still may be too hard for many average users (even
   with very helpful things like Enigmail for Thunderbird, etc.)

-- S/MIME is another option, but my impression is that most users and most
   sites don't have personal certificates deployed (although that may
   or may not change over time); I would note that in the federal space,
   because the Feds have been successful in deploying CAC cards, DoD folks 
   and other government employes now DO have the ability to send S/MIME 
   secured email. (If you'd like to try using S/MIME, I've got a one pager 
   on how to do that using a free personal certificate from Comodo and
   Thunderbird on a Mac; see:
   http://pages.uoregon.edu/joe/smime/using-smime-with-thunderbird.pdf )

-- If you work in a web-email environment, there are things like Hushmail
   or S-Mail that provide the option of having all intra-service email 
   automatically encrypted.

I would also note that there are also commercial products that handle
automatically encrypting and decrypting email on the user desktop with
PGP and/or S/MIME "without affecting the end-user email experience"
(this largely means that they hide the key management and/or cert 
management process from the end user)

If that's still too big a step to take, one can at least do things like
ensure that one's web email application only runs over https, and that
POP and IMAP connections use TLS, and that SMTP does opportunistic
encryption when both ends support it (yeah, it's not as good as 
message level digital signatures or message level encryption, and its
not what your consultant was suggesting, but anything you can do to 
harden email's a good thing, I think).

Just my two cents,

Regards,

Joe