Insecurities of Email

Note: I have included instructor comments and footnotes.

I originally set out to explore how secure (or not secure) email is, and what options are available to address any security shortcomings. I discovered along the way that there are three basic security flaws in email as we know it: what I will call "clear text", "anonymity" and "repudiation". In this paper, I intend to discuss the nature of each of these shortcomings, different solutions and how well they address the security flaws.

"Clear text"¹ as I use it in this paper means simply that most messages sent via email are not secure by nature. As a message travels from the sender to the recipient, any third party with access to the network can examine the contents of the message without the sender or recipient being aware.

"Anonymity" means that there is no way to verify that a sender is who he says he is. This anonymity opens the door to spam. Imagine if there were no way to send email anonymously: you would simply create one rule to ignore anything from spammer@spam.com and you would never have to worry about spam again.

Technically, "repudiation" is the refusal to acknowledge a contract (American Heritage Dictionary, 2000), or in this case, the refusal to acknowledge either sending or receiving a message. "Non-repudiation" is a service that would protect either the sender or the recipient from repudiation by proving either that the sender did send the message or that the recipient did receive the message. Consider two cases: the sender claims he did not send a particular message, or the recipient claims she did not receive a particular message. In both cases, one party may be potentially damaged by the other.

Ideally, we would want our email system to solve most if not all of these security flaws. I explored several different proposed solutions, some of which are already in use and some of which probably never will be.

ExMP serves as a replacement to Simple Mail Transfer Protocol (SMTP)². Instead of wrapping the message in text or MIME format, the message and all its parts are wrapped in XML data objects. Messages can be batched and delivered via Web Services over HTTPS. Upon receipt of a message, a mail server sends a confirmation to the originating mail server. If the message passes through one or more intermediary mail servers, each server sends confirmation as it receives the message. (Taylor, 2005)

ExMP solves the problem of clear text by encrypting the communication between servers. The drawback here is that each mail server along a message's route must be trusted.

The confirmation receipts would help protect against anonymity. If the receiving mail server asked the originating mail server if it sent a message, the originating mail server could respond affirmative, and the message would be delivered to the user. If the originating mail server responded negative (meaning it did not actually send that message), or if it did not respond at all the message could be discarded. Example: suppose jeff@domain.com sends a message through his mail server at domain.com. The destination mail server would ask domain.com if that message did in fact originate there, to which it would respond affirmative. Now suppose that a spammer sent a message pretending to be jeff@domain.com. In this scenario domain.com would respond negative, and the message could be discarded. Lastly, suppose that a spammer sent a message from xzy@xzy.com. The destination mail server would discover that there is no mail server at xzy.com, and discard the message.³

The confirmation receipts also help protect against repudiation, but not completely. With the receipts we can determine that a message originated at a certain server and was delivered to a user's mailbox. Since messages are confirmed to be from where they say they are, we could assume that the sender is who he claims, thus protecting the recipient from repudiation. ExMP does not offer any non-repudiation⁴ services for the sender, however. The most a sender can know is that his message was deposited in the recipient's mailbox.

In addition to the necessity of trusting each mail server a message might pass through, another drawback to ExMP is that the confirmation messages add significant overhead to the system. The biggest drawback, however, is that with so many millions of servers using SMTP, it is unlikely that we will move to a protocol that doesn't offer backward compatibility.

PKI is a way to exchange information securely using public/private key pairs. These keys are provided by a Certificate Authority (CA) that is assumed to be trusted. Each individual is given a private key and a public key contained in a certificate that he publishes on a web site or directory. The sender can "digitally sign" the message with his private key and the recipient can check the signature against the sender's public key. The sender can also encrypt the message with the recipient's public key and she can decrypt it with her private key.

There are two widely used standards of PKI for use in email: S/MIME and OpenPGP. S/MIME uses Public Key Cryptographic Standards (PKCS) while OpenPGP is based on Pretty Good Privacy (PGP). In PKCS, the CAs are usually large corporations. Anyone can verify the authenticity of a user's certificate by looking at who issued the certificate to him. Often there is a chain of issuers and eventually along this chain you should find a CA that you trust. If not, you can assume that the certificate is invalid and therefore not secure. OpenPGP works on a Web of Trust (WOT) schema. The authenticity of any individual's certificate is determined by how many other people have trusted that individual.

PKI solves the clear text problem easily.⁵ Messages are encrypted by the sender and can only be decrypted by the recipient. You can safely assume that all servers and networks the message passes through are untrustworthy, but it doesn't matter as long as they deliver the message.

PKI holds the potential to solve anonymity. When a message is digitally signed, it is pretty much guaranteed to be from who it says it is. Even so, there are ways to fool an end-user if his email software is configured to show "friendly" names instead of email addresses.⁶ The reason PKI doesn't solve anonymity completely is that most email users don't use it. If everyone that sent legitimate emails to you signed them, you could easily discard any unsigned emails as spam or untrustworthy. Since hardly anyone does, you still have to sift through unsigned emails that may or may not be from a trusted source.

PKI in itself doesn't wholly solve the problem of repudiation. The recipient can be reasonably confident that the author of a signed message is who he says he is. But, again, it does not help the sender when the recipient claims she didn't receive his message.

S/MIME defines a way to send signed return receipts when an email is received (RFC 2634 p. 9). Unfortunately, this provision assumes that the recipient is a fair participant⁷⁸. Of course, "if one could assume fair participants, then there would be no need for receipts in the first place" (Oppliger, 2004, p 76)

As stated above, one of the reasons PKI doesn't fully solve our security needs is that not everyone uses it. So why don't they? Two reasons are availability and ease of use. Governments were originally slow to allow the public to use strong encryption. Once the public had access to PKI encryption, the methods used to encrypt and decrypt were clumsy at best, and most users do not have the technical background or the patience required to learn it. So we have technology that can solve the problem of anonymity and clear text, but so far it isn't easy to deliver to the masses.

One proposed solution to this is to use a proxy server that sits between the client and the mail server. (Brown, 1999, 1051-1052, 1056) This proxy would be responsible for managing keys, encrypting and signing outgoing messages and verifying and decrypting incoming messages. The end-user only has to configure the proxy once, and all his messages will be secure. This approach would work in both commercial and home environments, as long as the physical network in the building was trusted.

Key management is a difficult issue because most users don't notice or even care much about security. Since most users don't worry about keeping their keys secure, IT departments, operating systems and other software does their best to manage keys in behalf of the users. As more and more users migrate to web-based email, key management becomes more difficult. Then we must consider also the case where a key is compromised. A CA can revoke the user's certificate and issue a new one with a new key, but most software doesn't check to see if a certificate has been revoked, which nullifies the security of the certificate.

Still, if these pitfalls can be overcome, PKI offers a near-complete solution to our security flaws. PKI is a mature technology that sits on top of current email protocols, so no one needs to update their servers to make it work.

So far the technologies I've discussed solve all but half of the repudiation problem: protecting the sender from the recipient denying that she received a message. There are proposed solutions to this problem, as well as some clever hacks.

My favorite "hack" is when the sender uses MIME to embed an image URL into the message. When the recipient views the message, the web server hosting the image makes a note that the recipient has opened that message.⁹ Because the problem of anonymity still exists, however, this presents another security flaw. It is not unreasonable to send a confirmation of receipt to a known party, but when the sender may be exploiting anonymity it is unreasonable to send confirmation of receipt. Most modern email applications provide an option to disable any linked objects.

Oppliger explores several different schemas for solutions, in two categories: those that require a Trusted Third Party (TTP) and those that don't.

While they are very interesting, schemas that don't involve TTPs are not practical. Both parties may exchange information and be certain that the other received it, but they usually require that both parties engage in a series of computations and message exchanges simultaneously. Email, by its nature, is asynchronous and doesn't lend itself to this. Schemas that require a TTP are much more complex, and as such care must be taken to ensure that the TTP does not become a performance bottleneck. (Oppliger, 2004, p. 78)

While "clear text" and "anonymity" are easily solved with current technology, we still lack comprehensive non-repudiation services. It seems that a reliable solution may have to come from a change in lower level protocols. Moving from one protocol to another will be resisted because of the cost alone. There would have to be a protocol that offered so much benefit that the cost of switching would be less than the cost of staying with STMP. On the other hand, cryptography is capable of solving the problems of clear text, anonymity and half of repudiation and may some day provide a complete solution.¹⁰

Oppliger, Rolf. (2004) Certified Mail: The Next Challenge for Secure Messaging. Communications of the ACM, Vol 47,No. 8, 76-79

Ellison, Carl, Schneier, Bruce. (2000) Risks of PKI: Secure Email. Communications of the ACM, Vol 43, No. 1, 160

Taylor, Steven, Watters, Paul A. (2005) Trustworthy E-mail Using Secure XML Web Services, Proceedings of the Seventh IEEE International Conference on E-Commerce Technology (CEC'05)

Brown, Ian, Snow, C. R. (1999) A Proxy Approach to E-mail Security. Software - Practice and Experience, 29(12) 1049-1060.

IETF RFC 2045

IETF RFC 2634

American Heritage Dictionary of the English Language, Fourth Edition, (2000) New York: Houghton Mifflin Co.