We got a lot of responses to yesterday's "fake Verizon" e-mail. This brings (again) up the topic of authenticating e-mail messages. If you are reading this post, you probably already realize that the "From" header, like anything else transmitted in a default email, doesn't do a thing to authenticate an e-mail message. There are a number of technologies that can be deployed to help this.

1 - SMTP over SSL

There are a number of methods to run SMTP and other mail related protocols over SSL (pop, imap...) . SMTP in particular frequently uses the "STARTTLS" protocol which can start an SSL connection "on the fly" if both servers support it. SSL however only protects the connection. The receiving mail server can verify the identity of the sending mail server, and the connection can be encrypted. In most implementations I have seen, the certificate is not verified, and the SSL connection is optional, which significantly reduces the value of this technique, in particular between mail servers. For mail clients sending e-mail to trusted mail servers, SMTPS can be a meaningful control if for example a VPN isn't available. But the main issue is that e-mail is forwarded from server to server, and the sender or recipient have no control if the path the email took was secure.

2 - DKIM

DomainKeys Identified Mail (DKIM) [1] is mostly an anti-spam feature. It will authenticate if a mail server is authorized to send e-mail on a particular domain's behalf. At this point, some major e-mail providers like Yahoo will implement DKIM. However, aside from its limited scope, DKIM suffers from a number of implementation issues. First of all, it is typically not a default component of mail servers, but has to be added on via a patch or additional software packages. Secondly, once implemented, e-mail for a particular domain has to be sent via authorized mail servers. A users working from home may no longer use his or her ISP's mail server, but has to send e-mail via the corporate mail server. In most cases, this is a good thing, but it can be difficult to implement. The neat part about DKIM is that keys are distributed via DNS, and that validation is done on the server without user involvement. Of course, the use of DNS also requires a secure DNS infrastructure.

3 - PGP

PGP is probably the oldest form of e-mail encryption and authentication. It does provide end-to-end verification of a message or part of a message. It is very flexible in that it can be used to verify the entire message, or just parts of it. Headers are usually not included in the signature, but since the signature is linked to an e-mail address, it can still be used to authenticate the sender. In my opinion, PGP (and GPG for that matter) suffers from two big problems: First of all, support is available for most e-mail clients, but usually not included by default, requiring users to install and configure additional software. Software for iOS for example is available, but poorly integrated with the default iOS mail client. Secondly, PGP key management is not intuitive to the average user. It lacks the use of a central "certificate authority" and leaves it up to the user to trust or not to trust a key. combined with the limited use of PGP in day-to-day e-mail use, this is a big challenge. Usually it is best to establish the validity of a PGP key by continuously using it for all e-mail, making it easier to spot unusual or different keys.

4 - S/MIME

S/MIME probably has the best chance at this point of gaining some acceptance. It does use certificate authorities, so unlikely PGP the decision to trust a certificate is removed form the user to some extend. But as other uses of certificate authorities have shown, this isn't all that safe either. However, I think for the average user (one that hasn't attended a key signing party yet), this is preferred over the decentralized method used by PGP. The main issue with S/Mime is that it does sign the entire message including headers, and there is no option to only sign part of the message. This leads to broken signatures if a message is forwarded to a mailing list or passes other remailers that change headers. But S/Mime has been widely implemented by default in many e-mail clients, including mobile clients.

I really wish more people would take advantage of any of these technologies to verify e-mail. Any e-mail, including e-mail sent by automated processes, should be signed. I think user awareness will follow once users see more signed e-mail. Most of the automated e-mail we sent for ISC/DShield uses PGP signatures and we are working on implementing it for more of our e-mail. DKIM hasn't been an option for us so far as our organization is too decentralized, and for our audience PGP has shown to work pretty well and easier to implement then S/Mime for our scripts. My personal e-mail is usually S/MIME signed. 

[1] http://www.dkim.org/

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter