Serverless Electronic Mail

07/09/2020 ∙ by Geoffrey Goodell, et al. ∙ UCL Google Inc 0

We describe a simple approach to peer-to-peer electronic mail that would allow users of ordinary workstations and mobile devices to exchange messages without relying upon third-party mail server operators. Crucially, the system allows participants to establish and use multiple unlinked identities for communication with each other. The architecture leverages ordinary SMTP for message delivery and Tor for peer-to-peer communication. The design offers a robust, unintrusive method to use self-certifying Tor onion service names to bootstrap a web of trust based on public keys for end-to-end authentication and encryption, which in turn can be used to facilitate message delivery when the sender and recipient are not online simultaneously. We show how the system can interoperate with existing email systems and paradigms, allowing users to hold messages that others can retrieve via IMAP or to operate as a relay between system participants and external email users. Finally, we show how it is possible to use a broadcast protocol to implement mailing lists and how distributed ledger technology might be used to bootstrap consensus about shared knowledge among list members.



There are no comments yet.


page 5

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Objectives

Third-party e-mail platforms operate control points that can, and often do, function against the interests and purposes of their users and the other e-mail users with whom their users correspond. However, the convenience offered by such platforms, coupled with the architecture of carrier networks and the mobility of user devices, typically prevents individual users from operating their own mail servers. In particular, many broadband and mobile carriers implement firewalls, either explicitly or de facto via network address translation, to block packets destined for servers operated by their clients. Carriers without such policies often assign their users dynamic addresses, rendering them unreachable as a means of receiving mail and untrusted by remote servers as a means of sending mail. As a result, although server software can certainly run on mobile devices such as laptops and phones, few users actually run such software, and platform operators such as Apple and Google have little incentive to promote a departure from this paradigm.

Tor onion services [4] offer an accepted way for users to reach each other directly. The operator of an onion service reaches out through the Tor network to establish a point of presence that other users can access over an end-to-end encrypted channel using a self-certifying name. Although the Tor relays, including the introduction and rendezvous points, facilitate the end-to-end connection between the Tor client and the onion service, they have no knowledge of the identities of the clients and services that they are connecting. Tor software runs on most mobile devices, and mail servers can be compiled to run on most mobile devices as well. It is therefore entirely possible for mobile devices such as phones and tablets, in addition to ordinary laptops and workstations, to run a combination of software utilities that can underpin a peer-to-peer e-mail network, and a package containing such utilities can be designed to interoperate with popular mail clients with minimal modification.

Next, we define the specific goals of our project, which we believe will increase the value of e-mail to its users and promote trust in the infrastructure that delivers it:

  1. Require end-to-end encryption between users. Although popular mail servers tout their use of client-to-server encryption as well as server-to-server authentication via SPF [5] and DKIM [6], ordinary customers of popular e-mail platforms still do not generally use end-to-end encryption technology. In contrast, our system would leverage peer-to-peer trust to provide real, usable security for its users.

  2. Eliminate third-party mail server operators. Electronic mail generally relies on network carriers to deliver messages from the source to the destination. If the sender and recipient are online simultaneously, then they can leverage anonymity networks to communicate without third-party mail servers to collect metadata about their conversations. Even when the sender and recipient are not online at the same time, there is no reason that these carriers must be giant platforms. In contrast, our system would leverage peer-to-peer relationships to deliver messages.

  3. Support multiple unlinkable identities per user. Most people use a small number of distinct email addresses to receive mail from a large number of different users. As a result, they implicitly create linkages among their many relationships that can be observed by third parties. Our system natively supports the establishment of an arbitrary number of unlinkable identities for each user. By not providing a way for an individual to prove that two identities are linked, we reduce the chance that linkages will be forcibly discovered by an adversary.

2 Comparison to Other Projects

Anonymous, web-based e-mail accounts are already available on the Internet. Unfortunately, such e-mail accounts are generally incompatible with ordinary mail client software and business processes, and they usually have few features and service-level assurances. They also rely upon third-party operators, who might block access or simply stop working at any time, thus resisting the establishment of long-term identities or addresses. So we need something different. There are a few notable projects that put the users in the center of the architecture; we compare our system to theirs in terms of requirements:

  1. Mixminion, a “Type III Anonymous Remailer” [7]. Mixminion uses mix networks to batch, mix, and resend anonymous e-mail messages through a network of remailers. Mixminion extends the Mixmaster [8] protocol in several ways, notably by introducing reply blocks to facilitate secure replies to an anonymous sender. Mixminion is designed to tolerate high latency, so theoretically its anonymity properties could be better than Tor, which is designed for low-latency applications and therefore introduces a vulnerability to timing attacks. Although Mixminion has been released, it has not been under active development since 2013, and its developers do not recommend its use [9]. In contrast, our system is explicitly designed for low-latency operation, in part because we believe users do not want to wait for their mail, and in part because the Tor anonymity network delivers a much larger anonymity set that has already been bootstrapped. Additionally, although our system can be used to send and receive anonymous e-mail messages, we do not anticipate that will be its typical use case. We imagine that in most circumstances the senders and recipients will know who each other are. Nevertheless, the system relies upon the anonymity of the Tor network to protect users from network adversaries and to ensure that the application itself is not blocked.

  2. Cwtch, an “Infrastructure for Asynchronous, Decentralized, Multi-Party, and Metadata Resistant Applications” [10]. Cwtch is an extension of the Ricochet [11] protocol, which provides real-time instant messaging using Tor onion services. Cwtch extends Ricochet by allowing asynchronous group messaging. In contrast, despite the fact that our proposal anticipates low latency, our system is not principally intended for real-time instant messaging. We assume that typical messages can be lengthy, with rich features and attached files, and we assume that typical users will want to read each one individually and at their convenience. We further assume that users will often be offline when communication takes place, as they would for ordinary e-mail. For all of these reasons, our system does not use Ricochet and instead relies upon ordinary SMTP for passing messages.

3 System Requirements

We imagine that a user of our proposed system will have access to the Internet and a device that can accommodate Tor client software, an SMTP client, and an SMTP server. Nearly all modern workstations and laptops running Linux, Windows, MacOS, or a BSD derivative will satisfy the device requirement. Smartphones and tablets will usually satisfy this requirement as well, although users are advised that, depending on the specific restrictions imposed by their device vendors, they might need to install a custom operating system to install the requisite software applications.111Important differences exist between the iOS and Android development platforms. Although data-harvesting might be a larger part of the revenue model for Google, Apple’s role as gatekeeper in the iOS platform might encumber an effort to deploy systems like ours [12].

The Tor client software must be configured to allow a helper application to operate persistent Tor onion services via the Tor Control Protocol [13]. The user shall also have compliant e-mail software, including a modified mail server that can accommodate the behaviour defined in this document. The user should also have a modified mail client that can facilitate the behaviour defined in this document. Depending upon how the server is implemented, such modifications might not be strictly required, although we imagine that appropriate client modifications could significantly improve the user experience and value of this system. The user should also have suitable PGP software [14]; we assume this will be OpenPGP [15].

4 System Design Overview

From: Alice <user@wxu6pped7wv3.onion> To: Bob <user@0xiq82snnr09.onion> Message: …


Figure 1: If Alice runs a mail client and server on her device and Bob does the same, then Alice can send mail directly to Bob using Tor onion services. The channel from Alice’s Tor client to Bob’s Tor client is protected by end-to-end encryption.

The elemental feature of our design is pairwise communication between two parties via SMTP over Tor, wherein each user operates at least one (and probably more than one) Tor onion service that relays traffic to an SMTP server, as illustrated by Figure 

1. The SMTP servers are not generally intended to be available outside the Tor network, and that therefore the system does not rely upon Tor exit relays for its operation. Most Tor exit relays disallow traffic exiting to common TCP ports used for SMTP anyway, although this is not a concern for the system we describe.

4.1 Personal Introductions

From: Bob <user@0xiq82snnr09.onion> To: Alice <user@wxu6pped7wv3.onion> Message: Carol <user@2gqisa2z13oj.onion>



From: Alice <user@wxu6pped7wv3.onion> To: Carol <user@2gqisa2z13oj.onion> Message: …


Figure 2: Bob can introduce Alice to Carol by including contact details for Carol in a message to Alice. Then Alice can send a message to Carol directly. The combination of Bob’s introduction and the self-certifying Onion address form the basis for trusting Carol.

Before they can send mail to each other via our system, the users will need to have received the in-system e-mail addresses of their counterparties. This can be accomplished in several ways:

  1. Manually added by the user.

    1. One-to-one messaging via an external channel. Of course, it is possible for a community to share such addresses with each other by exchanging files over any other digital medium, including regular messaging with servers to support e-mail or chat.

    2. Via a web page or message board. Web pages or message boards could advertise e-mail addresses for use within this system.

    3. In person. This could be done with near-field communication or QR-code scanning by a mobile device. The QR-code scanning could be device-to-device, or it could involve a device scanning a posted or printed advertisement.

  2. Automatically added via communication within the system.

    1. In-system introductions. Once two counterparties know how to reach each other, they can introduce each other to third parties, as illustrated in Figure 2.

    2. Mailing lists. One user can invite another to participate in a mailing list by sharing the name of the list and agreeing to forward list messages in one or both directions. For example, Bob can agree to forward messages from Alice to the list, or from the list to Alice, or both; we describe mailing lists in Section 4.4.

4.2 Message Delivery

From: Alice <user@wxu6pped7wv3.onion> To: Carol <user@2gqisa2z13oj.onion> OpenPGP Key Request

From: Carol <user@2gqisa2z13oj.onion> To: Alice <user@wxu6pped7wv3.onion> OpenPGP Key Response: 0k4jnr1l701a



From: Alice <user@wxu6pped7wv3.onion> To: Carol <user@2gqisa2z13oj.onion> For: Carol <user@2gqisa2z13oj.onion> Message: […] encrypted to 0k4jnr1l701a



Figure 3: Once Alice knows how to reach Carol, she can request Carol’s OpenPGP key. This step can be implemented automatically via the headers of messages that Alice and Carol send to each other, for example using reply blocks. With Carol’s OpenPGP key, Alice can send encrypted messages to Carol that can be stored and forwarded if required. (Note: the padlock with the ‘E’ symbol on the envelope indicates that the message is encrypted from Alice’s message-writing application to Carol’s message-reading application.)

Once two parties are able to communicate with each other using our protocol, then they can rely upon Tor to ensure that the channel over the network between them is encrypted. However, the use of Tor onion services does not automatically ensure that their applications can verify the authenticity of messages, and indeed there is no specific protection for the message between the endpoint of the Tor service and the recipient’s mail client. This is important for two reasons. First, most mail clients assume that mail is persistent, not ephemeral, and OpenPGP [15], the established mechanism for exchanging end-to-end encrypted messages, would operate outside the security envelope of Tor. Second, users might want third-parties to carry messages for them, a desideratum that is particularly important when the recipient is not online at the time that the sender sends the message.

To address this concern, we specify a mechanism by which two parties can mutually exchange their OpenPGP keys [15], relying upon the security envelope provided by Tor to ensure that the message is not intercepted by network adversaries. Once the users have exchanged their OpenPGP keys in this manner, they can exchange messages that are end-to-end encrypted and suitable for persistent storage, as shown in Figure 3.

From: Alice <user@wxu6pped7wv3.onion> To: Bob <user@0xiq82snnr09.onion> For: Carol <user@2gqisa2z13oj.onion> Message: […] encrypted to 0k4jnr1l701a




From: Alice <user@wxu6pped7wv3.onion> To: Carol <user@2gqisa2z13oj.onion> For: Carol <user@2gqisa2z13oj.onion> Message: […] encrypted to 0k4jnr1l701a



Figure 4: Message Carriers. If Carol is not online when Alice tries to send a message, then Alice can encrypt the message with Carol’s OpenPGP key and send it to Bob, whose software can subsequently try to send the message to Carol on behalf of Alice, even if Alice goes offline. Note that SMTP explicitly recommends a way for Bob to periodically resend the message until it succeeds.

Bob <user@0xiq82snnr09.onion> Carol <user@2gqisa2z13oj.onion> via Bob <user@0xiq82snnr09.onion> OpenPGP Key: 0k4jnr1l701a


Address Book
Figure 5: Address Book Function. It is assumed that Alice’s mail client will maintain a mapping that includes metadata such as the provenance of the introduction, designated carriers of messages, and public cryptographic keys for each contact.

Users who are able to send end-to-end encrypted messages can also rely upon carriers to forward messages on their behalf, as shown in Figure 4. This feature is useful when the recipient is not online at the time that a message is sent; in such circumstances we propose that a third party can relay the message at the behest of the sender, thus addressing the availability problem that mail servers intend to solve. Carriers using SMTP will be able to perform best-effort delivery just as an ordinary mail server would. The main benefit of using a carrier is to decouple the timeliness of delivery from the sender’s online status, thus improving the chance that the recipient will receive the message as soon as possible.

Users would have the option to exchange information about carriers that they mutually trust for this purpose. Trust will still be needed even whilst the messages are encrypted, not only because carriers might fail to forward the messages, but also because carriers would be able to observe the presence of a conversation between sender and recipient, even if the conversation itself is encrypted. For this reason, although it is possible for anyone to carry messages for anyone else, and perhaps even possible for users to act as “professional carriers” in exchange for a fee, it is not assumed that senders would trust arbitrary users to act as carriers, nor is it assumed that arbitrary users would want to act as carriers for senders (or recipients) that they do not trust. We assume that users will keep track of OpenPGP keys and lists of trusted carriers in local address books, as shown in Figure 5. In particular, one particular user might keep track of the specific user responsible for the introduction to a third user, and the set of introductions to the same user can form the basis of a list of designated carriers.

Although we imagine that in most cases a sender would only use a carrier after failing to deliver the message directly, we assume that a user can opt to send messages via multiple carriers at the same time, and perhaps also attempt direct contact with the recipient similarly. We further assume that the recipient’s software will delete (and possibly track) any duplicate messages. If a recipient, Carol, knows that a specific third-party, Bob, often acts as a carrier, then Bob’s software and Carol’s software may allow Carol to explicitly ask Bob to forward any messages that he holds for her, although this is not required. We assume that carriers will also have the option to inform senders that a message was sent successfully, although end-to-end delivery confirmation can be handled by established SMTP headers [16].

4.3 Accounts and Forwarding

From: Alice <user@wxu6pped7wv3.onion> To: David <david@0xiq82snnr09.onion> Message: …




From: Alice <user@wxu6pped7wv3.onion> To: David <david@0xiq82snnr09.onion> Message: …


Figure 6: Accounts. If desired, Bob can also handle mail for David directly. In this setup, Alice sends mail to Bob’s device, and David pulls it from Bob via IMAP (via Tor, or not).

Users of this messaging system can provide services to communicate with others who might not run their own mail server software. For example, a user of the system can provide an account for someone who might or might not be a user of the system, as shown in Figure 6. Mail for the external user (David, in our example) that is received by the carrier (Bob, in our example) can be stored in an account on the carrier’s device. Then, the external user can access the account via an ordinary mail-access protocol such as IMAP [3], which can be offered to the external user as a Tor onion service. (It would also be possible for the carrier to offer the account to the external user without using a Tor onion service, although this might not work if the carrier is behind a firewall or NAT.)

Bob might be motivated to provide an account to David for a variety of reasons. For example, Bob might be David’s employer or business partner, or Bob might offer David an always-on service to receive messages from anonymous senders more reliably in exchange for a fee.

From: Alice <user@wxu6pped7wv3.onion> To: Bob <user@0xiq82snnr09.onion> For: David <> Message: …



ordinary SMTP

From: Alice <> To: David <> Message: …


Figure 7: External Forwarding. If desired, Bob can deliver mail to David at an external address. In this setup, Alice sends mail to Bob’s device, and Bob forwards it to David via ordinary SMTP. Later, when David wants to reply to Alice, he is provided an address for Alice that instructs Bob’s mail server to forward it appropriately.

Users of this messaging system can also exchange messages with others who have external e-mail accounts, as shown in Figure 7. In this case, messages for external users (David, in the example) would be sent to the carrier (Bob, in the example) with a special tag specifying the external user to which the message must be forwarded. Then, the SMTP server running on the carrier’s device will create a new message containing the contents of the original message and send it via ordinary SMTP to the external user. To facilitate replies, the new message will provide an address for the sender consisting of a username encoding the in-system e-mail address of the sender and a hostname corresponding to the externally reachable address of the carrier’s mail server.

4.4 Mailing Lists

Finally, the system can be used to implement decentralised mailing lists that do not rely upon a mailing list server. Such mailing lists would rely upon pairwise relationships among list members. We assume that each participant in a mailing list will have exchanged OpenPGP keys and agreed to receive messages from at least one of the other participants. We further assume that the graph formed by those pairwise connections is fully connected. Then, a gossip protocol can be used to share messages through the entire network and, as long as all participants remain connected and continue to share messages, every message will eventually reach every user. Gossip protocols can be optimised to reduce the total number of messages in several ways, such as using randomised delays to reduce the chance that messages will cross paths, establishing agreement among participants to maintain sparseness by policy, or explicitly selecting a spanning tree [17].

From: Alice <user@wxu6pped7wv3.onion> To: Mailing List XYZ <list-xyz@0xiq82snnr09.onion> Message: […] signed by Alice (c2mx4chcyf59)




From: Alice <user@wxu6pped7wv3.onion> To: Mailing List XYZ <list-xyz@2gqisa2z13oj.onion> Message: […] signed by Alice (c2mx4chcyf59) countersigned by Bob (g495k17w89xi)



Figure 8: Mailing Lists Mailing lists can be implemented using a gossip protocol among a set of pairwise-linked network list participants. Members shall forward messages to each other and break cycles by rejecting duplicates. Rate-limiting and filtering rules can be implemented by individual list members using the signature on the message. Members can also authenticate message carriers by requiring each message sent to a list to be countersigned by the peer that forwarded the message. It is possible to use a distributed ledger to establish consensus about the set of messages that have been sent to the list, the sequence of the messages, or the agreed-upon state of a system based upon the aggregation of the messages. (Note: the padlock with the ‘S’ symbol indicates that a message is signed.)

Figure 8 illustrates how a message would be sent and propagated among a set of list participants. List members would propagate a message through the network link by link, each member receiving messages from one of its neighbours and passing it to its other neighbours, discarding any duplicates. We assume that a message received by a list member would be signed by the original author and that the entire message and the signature by its original author would be countersigned by the neighbour from which it was directly received. Then, the list member can decide whether to propagate the message based upon its policy and the validity of the signatures.

It is possible to use a distributed ledger to help ensure the completeness of the list conversation. For example, a list could require that each message includes a hash of the previous message, and that an invalid hash would cause a message to be rejected for propagation by policy. It is also possible to use a distributed ledger to keep track of the consensus state of something on behalf of the entire group. For example, a distributed ledger could be used to track and serialise the changes to a document, a record of transactions of tokens, or a series of calculations.

5 Security Considerations

The following is a partial list of security considerations that are important to the design of systems that make use of the protocol described in this document:

  1. Identity revocation. In the absence of a centralised authority or revocation server, users will need to share revocation announcements with their peers. Two forms of revocation are important: the revocation of a user’s onion service address, and the revocation of a user’s OpenPGP key. Both could be handled in a peer-to-peer manner by sending revocation messages to a user’s known peers, or through the use of a third-party keyserver.

  2. Managing multiple devices. Users could copy their Tor onion service keys and their OpenPGP keys to multiple devices, although it is the responsibility of the user to ensure that only one Tor onion service is active at a given time for a given Tor onion service key. Users could also use different keys for different devices and use them as carriers for each other.

  3. Attacks to link multiple identities for a user. Users should be careful to control the set of parties with whom they share their addresses, in case they want to establish different identities and ensure that they stay unlinked. Also, adversaries could employ timing attacks to statistically link different identities that simultaneously operate on the same device. The fact that users can make introductions does not prevent them from having multiple identities for use with different groups or in different contexts.

6 Contexts

Identity, like motion, is not absolute and is always relative. Put another way, identity is a matter of perspective. A simple way to think of the meaning of context is as a ‘path of connection’. If Bob introduces Carol to Alice, then we might say that Alice knows Carol through Bob. Now, Alice might already happen to know Carol, or not, but there is no reason why Carol would use the same identity every time she communicates. Carol has an incentive to represent herself differently to everyone that she meets, so that she can control the linkages among the identities that she uses in different contexts [18]. Of course, this does not work so well if Bob is doing all of Carol’s introductions for her. Even if Bob and Carol agree to use a different identity for Carol in each of the introductions he makes for her, Bob cannot prove that the Carol he introduces is anyone other than his own fabrication, and he cannot prove that any two introductions he makes are or are not the same fabrication.

For this reason, there is value for being introduced to the same person via multiple channels. If David and Bob both introduce the same Carol to Alice, then Alice knows that Carol is someone whose identity David and Bob agree upon. It could still be that David and Bob have conspired to invent Carol, but that possibility is less simple than something that they could each have invented independently. Conversely, Carol might have one identity that Bob uses to introduce her to Alice and a different identity that David uses to introduce her to Alice, in which case Alice might assume that these are two different people when in fact they are not.

In human interaction, we are generally able to have many different identities. When I enter a coffee shop, the barista generally does not know any of my other identities or the link between me and those identities, so I am free to create an entirely new one. This is actually a great privilege, since I am unburdened by other contexts. Interestingly, it is a privilege that celebrities lack. If Boris Johnson were to enter a coffee shop in central London and attempt to create a new identity, he would be out of luck, precisely because of the pre-existing context that already binds him.

7 Acknowledgements

The author would like to thank Patric de Gentile-Williams for providing perspective and insight.