Distributed mailing lists

Ian Brown and Ian Grigg

Abstract

Introduction

Fundamentally, a mailing list is simply a collection of e-mail addresses that is used by a piece of software to send e-mail to all members of the list. Current implementations such as MajorDomo [1] and ListServ [2] are centralised services. A user sends a message to a central point, which is then forwarded by a list server to all members of the list (see figure 1). The list server manages the list, often allowing members control over their own details on the list.

There is no reason, however, why a mailing list could not work in a distributed manner. Members of the list would maintain their own view of the list. This increases the resilience of the mailing list to failure or attack. Centralised systems are completely dependent on the operation of their central node. Failure of a node in a distributed mailing list affects only that node (see figure 2).

Two separate issues are involved in running a distributed mailing list. The list must be created and managed securely and reliably. A mechanism must also exist for messages to be sent to the list.

List management

Group membership protocols such as [3] allow principals in a system to agree on a common group definition. They are commonly used by distributed processes to agree on a set of currently operational processes. Processes that fail need to be removed from the list; new processes need to be added. All group members must see these changes consistently. These protocols are resistant to the failure of group members. [4] adds resistance to the effects of a malicious intruder. Corrupted processes in or outside the group cannot affect the group view of correct processes. Malicious processes cannot alter or prevent the alteration of a group without the collusion of a significant number of other group members.

A similar protocol is required for distributed list management. Mailing lists are less demanding than distributed systems, however. While e-mail authors may disagree, one mail that is not sent to a group member is not disastrous. If a distributed process does not receive data, it may lose synchrony with other processes and behave incorrectly. An incorrect list control message sent to – or not sent to – a mail group member will cause it to send or not send mail to other group members incorrectly. Distributed processes receiving control messages incorrectly will behave completely incorrectly and may cause the failure of the whole distributed system.

Mail distribution

The widely used Simple Mail Transfer Protocol [6] vastly simplifies mail distribution. It allows one e-mail to be sent to any number of recipients. If the sender of a mail knows the members of a mailing list, the message can be sent directly to them all. Such messages are highly resistant to failure or attack. SMTP’s store and forward nature, combined with TCP/IP’s re-routing capabilities, reduces the effect of link failure. Only an active attack or malfunction in an SMTP server while it is processing a message will cause its loss.

Mail security

Public-key cryptosystems such as RSA [7] are often used to provide authentication and confidentiality for mail. Messages are digitally signed and then encrypted with the recipients' published public keys. Only the recipients' closely-guarded private keys can decrypt the resulting ciphertext message.

In centralised mailing list systems, list members do not know the identity of all other list members. They therefore cannot encrypt messages in this manner. A secret key shared between all group members could be used to encrypt and decrypt messages using a symmetric cryptosystem such as IDEA[8], but would be prone to disastrous compromise. Alternatively, it would be possible to provide sender->server and server->recipient security, rather than direct sender->recipient protection, by encrypting messages to the list server's public key. The server would then decrypt incoming messages before re-encrypting them to each member of the mailing list. This would make the server's private key very valuable to an attacker, and place a high computational load on the server. While an attacker only needs one list member's private key to gain access to messages, this list member may subsequently leave the group. The server's private key is less likely to change, making it a better target. This key would need to be permanently available on the networked list server, which is poor security practice.

An alternative is to use proxy cryptography on the server. This allows a message encrypted to Alice to be re-encrypted to Bob without needing access to Alice's private key or the message contents, using an encryption proxy key generated by Alice. Alice must unconditionally trust Bob, since the proxy key allows him to decrypt her messages. Symmetric proxy schemes also require Bob to trust Alice, as Alice can decrypt his messages given the proxy key and her own private key. Asymmetric proxy functions remove this ability and thus the need for two-way trust. Finally, active asymmetric schemes require Bob's co-operation to allow Alice to produce a proxy key. A passive asymmetric scheme requires only Alice's private key and Bob's public key [9].

A list server administrator could create proxy keys for each member of the list. Messages arriving at the server would be re-encrypted to each list member without requiring the server's private key to be available. An asymmetric scheme should be used, as it is not appropriate for the list server to be able to decrypt messages to its members! A passive asymmetric function would greatly reduce the effort required to create the proxy keys.

Ideally, the proxy keys would not leave the server. When a list member left the group, the destruction of their proxy key would prevent them decrypting messages en-route to the server. If this was not possible, the list server would need to change its private key every time a group member left.

Proxy cryptography greatly increases security for a centralised scheme, but still requires computational effort from the server to create proxy keys and re-encrypt messages with them. A distributed mailing list removes the need for this complexity. List members are aware of each others' identity, and can therefore directly encrypt a message with all of its recipients' keys. If members of the list wish to conceal their identity, they can use digital pseudonyms [10].

Centralised vs. distributed mechanisms

List control and mail distribution can vary independently on a scale from totally centralised to completely distributed. At one extreme are current list servers, with centralised list control and mail distribution. At the other would be a completely distributed system. Between these two points are other useful application scenarios.

Centralised systems have large economies of scale and are thus appropriate for large lists. They are efficient to administer at such sizes. Messages can be moderated, and one central point of access can be advertised. Participating nodes require no software other than standard mailers, although the central server can be complex to set up. If one person is willing to shoulder this burden, or wishes to control the group, this scheme is appropriate. The centre is extremely vulnerable, however. Failure or subversion of this node is disastrous.

Delegation of mail distribution substantially reduces this risk. Particularly in small, closed groups, e-mail is sent far more frequently than group changes occur. This scheme is also useful where several groups of people are communicating with poor inter-group connectivity but good intra-group communication. An example of this scenario is a list composed of several large organisations using different e-mail systems. Each site would run a mail distribution centre for sending messages internally, and communicate with other centres for external message transmission (see figure 3).

While list control remains centralised, failure of this controlling node does not hinder the ability of the group to communicate – only to be changed. The greater the delegation of mail distribution, the smaller the effect of a node failure will be. Such groups are still vulnerable to active attack on the list control node.

Distributed list control weakens this vulnerability. Group members act democratically, voting on proposed changes and accepting the will of the majority. Such systems can be made resistant to subversion of a large fraction of their membership using techniques (such as electing a 'leader' but allowing their impeachment) outlined in [4]. This type of scheme is useful for small groups of people communicating using systems that are vulnerable to failure or attack.

This paper describes the design and implementation of such a system, then analyses its effectiveness.

Design

Mail distribution protocols such as SMTP [6] are well-defined and in widespread use. This section therefore concentrates on the design of the control messages used to set up and manage distributed mailing lists.

It cannot be assumed that list members have good network connectivity. To take part in a mailing list, they must have acceptable mail connectivity. Mail is therefore used to transport these control messages, as in current systems such as MajorDomo [1]. The store and forward nature of SMTP also increases resistance of the system to link failure.

Security

Control messages require authentication and possibly confidentiality. E-mail messages should ideally have both. To provide these services, the Open PGP [11] standard was used. This specifies formats for encrypted and signed data and symmetric and asymmetric keys. Toolkits such as [12] are available to use these formats. The standard method of wrapping Open PGP data into e-mail messages, PGP/MIME [13], was used.

List setup

Centralised lists are set up by the administrator of the list server. Distributed lists do not have such a figure. Instead, our system allows anyone to propose a list and invite others to join it. The invitation contains the name and description of the group, policies and the suggested membership. Full disclosure is made at this stage to all invitees to allow them to make an informed decision whether to join - at which point they would receive the information anyway. It is the group proposer's responsibility to ensure invitations are restricted appropriately. Invitations are signed by the proposer, and contain their public key.

RSVPs are returned to the proposer by invitees, accepting or declining the invitation. Acceptances include the e-mail address to use for list correspondance and the public key which will authenticate all further control messages from this user. If it is a signature-only key, the acceptance must also include an encryption key. The RSVP should be signed and encrypted.

After collating the RSVPs, the proposer calculates the list membership. This is sent to all members. At this point, the list is created.

The list is vulnerable to attack until this stage. The proposer is a central node whose failure between sending out the list invitation and the final membership will prevent creation of the list. An attacker who noticed a list proposal they wished to prevent needs only to incapacitate the proposing node to prevent list creation.

The alternative would be for group invitees to send RSVPs to all other invitees instead of just the proposer. As soon as a list was proposed, it would be safe from attack on one central node. As list size increases, the number of RSVPs would increase O(n²) rather than linearly. This increases the opportunity for a denial of service attack on a user's mailbox. An attacker needs simply to propose a list to a large number of people, who will then do his work of flooding each other with mail control messages. Our scheme removes this danger, and sends only one message to users who may be uninterested in joining a list. It also ensures that all list members have an initial consistent view of the group. List proposals can be encrypted to reduce the ability of attackers to selectively attack lists they dislike.

List management

Once a list is set up, members may need to be added or removed or have their details modified. Centralised list server administrators simply need to alter the list themselves. A distributed group needs to alter the lists of all of its members. A centralised system could give the group proposer the responsibility of updating the list, by sending out control messages to all members. This would create a vulnerability to denial of service and group hijacking. If the proposer node failed, the group would be immutable. If the signature key of the proposer was obtained, an attacker could send authenticated control messages to group members and alter the group.

Instead, our system devolves as much responsibility as possible to group members. A user is the best person to know when their details have changed; therefore only they are allowed to alter their details in group members' lists. Similarly, only users are allowed to remove themselves from a list. While this prevents a disruptive group member being ostracised from a list, it greatly reduces the ability of an attacker to remove an individual. In the last resort, a new group can be formed excluding an unwanted member.

This leaves adding a list member as the difficult case. Without centralised control, who should have the ability and responsibility of adding addresses to the list? Restricting this availability increases the effectiveness of a denial of service attack, while extending it increases vulnerability to group hijacking. A complex voting system such as that in [4] could alleviate this dilemma, but would add massive complexity to the system - particularly using an asynchronous communication mechanism such as mail. Increased complexity in a system usually leads to reduced security.

Protocol

Implementation

Conclusion

References