Network Working Group P. Resnick, Ed. Request for Comments: 4417 IAB Category: Informational P. Saint-Andre, Ed. JSF February 2006 Report of the 2004 IAB Messaging Workshop Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA. The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB.
1. Introduction ....................................................3 2. Methodology .....................................................4 3. Issues ..........................................................5 3.1. Authorization ..............................................5 3.2. Multiple Communication Channels ............................6 3.3. Negotiation ................................................8 3.4. User Control ...............................................9 3.5. Message Transport ..........................................9 3.6. Identity Hints and Key Distribution .......................10 4. Recommendations ................................................11 4.1. Authorization .............................................11 4.2. Multiple Communication Channels ...........................12 4.3. Negotiation ...............................................13 4.4. User Control ..............................................13 4.5. Message Transport .........................................14 4.6. Identity Hints and Key Distribution .......................16 5. Security Considerations ........................................16 6. Acknowledgements ...............................................16 Appendix A. Participants .........................................17 Appendix B. Pre-Workshop Papers ..................................18
types of messaging under consideration. Among the themes identified were the following: o Authorization of senders and recipients o Negotiation of messaging parameters o Consent models and privacy o Identity hints, reputation, and key distribution o Cross-protocol unification of messaging models o Enabling greater user control over messaging o Transport issues (unreliable links, push/pull, etc.) o Message organization (e.g., conversations and threading) Purposely missing from the foregoing list is the topic of unsolicited commercial email or unsolicited bulk email (UCE or UBE, colloquially known as "spam") and analogous communications in other messaging environments such as instant messaging ("spim") and Internet telephony ("spit"). While this topic was an impetus for the IAB's holding the workshop, it was kept off the workshop agenda due to concerns that it would crowd out discussion of other messaging- related issues. The more general topics of authorization and identity were thought to be broad enough to cover the architectural issues involved with spam without devolving into more unproductive discussions. This document is structured so as to provide an overview of the discussion flow as well as proposed recommendations of the workshop. Section 3 summarizes the discussions that occurred during the workshop on various topics or themes, while Section 4 provides an overview of recommended research topics and protocol definition efforts that resulted from the workshop. Section 5 provides some perspective on the security-related aspects of the topics discussed during the workshop. Appendix B lists the pre-workshop topic papers submitted by workshop participants as background for the workshop discussions. Appendix B of this document. During the workshop itself, discussion centered on several topics or themes, as summarized in the following sections. Naturally, it was not possible in a two-day workshop to treat these topics in depth; however, rough consensus was reached on the importance of these topics, if not always on the details of potential research programs and protocol standardization efforts that might address the issues
raised. It is hoped that these summaries will inspire work by additional investigators. The in-workshop discussions quite naturally fell into three kinds of "tracks": (1) possible engineering tasks to recommend to the IESG and other standardization groups, (2) "blue sky" research topics to recommend to the IRTF and other researchers, and (3) general architectural or "framework" issues for consideration by both engineers and researchers alike. After a full-group discussion each morning to identify possible topics for more in-depth investigation, participants self-selected for involvement in one of three "break- out" sessions. Toward the end of each day, the full groups reconvened, gathered reports from the break-out discussion leaders, and attempted to come to consensus regarding lessons learned and recommendations for further research. The results of the two-day workshop therefore consist of discussion issues and research/ engineering recommendations related to the six topics described in this report.
Reputation systems may be especially worthy of future research, since they emulate a pattern that is familiar from real life. (It may also be valuable to distinguish between (1) reputation as the reactive assessment of a sender created by one or more recipients based on message history and (2) accreditation as a proactive assessment provided by trusted third parties.) Reputation might be based on summing an individual's "scores" provided by recipients on the network. (Naturally, the more important reputation becomes, the more bad actors might attempt to sabotage any given reputation system, so that a distributed as opposed to centralized system might be more desirable.) The actions taken by any given recipient based on the sender's reputation would not necessarily be limited to a simple allow/deny decision; more subtle actions might include placing messages from individuals with lower reputation scores into separate inboxes or redirecting them to other media (e.g., from IM to email).
o It may be worthwhile to define frameworks or protocols for recipient-defined delivery rules. Currently, routing decisions tend to be made mostly by the sender through the choice of a messaging channel, but in the future the recipient may play a larger role in such decisions. o The logic behind contact publication needs to be explored, for example, whether it is an aspect of or extension to presence and whether contact addresses for one medium are best obtained by communicating in a different medium ("email me to get my mobile number"). A multiplicity of delivery channels also makes it more complex for a senders to establish a "reliable" relationship with a recipient. From the sender's point of view, it is not obvious that a recipient on one channel is the same recipient on another channel. How these recipient "identities" are tied together is an open question. Another area for investigation is that of recipient capabilities. When the sender does not have capability information, the most common result is downgrading to a lowest common denominator of communication, which seriously underutilizes the capabilities of the entire system. Previous standards efforts (e.g., LDAP, Rescap, vCard, Conneg) have attempted to address parts of the capability puzzle, but without great success. The existing deployment model uses several out-of-band mechanisms for establishing communications in the absence of programmatic capabilities information. Many of these mechanisms are based on direct human interaction and social policies, which in many cases are quite efficient and more appropriate than any protocol-based means. However, a programmatic means for establishing communications between "arms length" parties (e.g., business-to-business and business-to- customer relationships) might be very beneficial. Any discussion of relationships inevitably leads to a discussion of trust (e.g., "from what kinds of entities do I want to receive messages?"). While this is a large topic, the group did discuss several ideas that might make it easier to broker communications within different relationships, including: o Whitelisting is the explicit definition of a relationship from the recipient's point of view, consisting of a list of senders with whom a recipient is willing to engage in conversation. While allow lists can be a workable solution, they are a relatively static authorization scheme.
o Token-based authorization enables the recipient to define a one- time or limited-time relationship with a sender. The issuer possesses a token that grants a limited-time right to communicate with the recipient. This is a more dynamic authorization scheme. o Rule-based authorization involves an algorithmic assessment of the viability of a relationship based on a wide set of criteria. This is a more general authorization scheme that can incorporate both allow lists and tokens, plus additional evaluation criteria such as message characterization and issuer characterization.
endpoint represents the same entity over time may not be warranted (it is possible that further work in identifying, addressing, and discovering endpoints may be appropriate, even at the URI level). It is also possible that the same endpoint or entity could be available via different transport mechanisms at different times, or even available via multiple transports at the same time. The process of choosing an appropriate transport mechanism when there are multiple paths introduces addressing issues that have not yet been dealt with in Internet protocol development (possible heuristics might include predictive routing, opportunistic routing, and scheduled routing). For links that can be unreliable, there may be value in being able to gracefully restart the link after any given failure, possibly by switching to a different transport mechanism. Another issue that arises in cross-media and cross-transport integration is synchronization of references. This applies to particular messages but might also apply to message fragments. It may be desirable for some message fragments, such as large ancillary data, to be transported separately from others, for example small essential text data. Message fragments might also be forwarded, replicated, archived, etc., separately from other parts of a message. One factor relevant to synchronization across transports is that some messaging media are push-oriented (e.g., IM) whereas others are generally pull-oriented (e.g., email); when content is pushed to a recipient in one medium before it has been pulled by the recipient in another medium, it is possible for content references to get out of sync. If message fragments can be transported over different media, possibly arriving at separate times or through separate paths, the issue of package security becomes a serious one. Traditionally, messages are secured by encrypting the entire package at the head end and then decrypting it on the receiving end. However, if we want to allow transports to fragment messages based upon the media types of the parts, that approach will not be feasible.
once one has created a public/private key pair and certified the public key, it is less than obvious how to distribute that certificate or discover other people's certificates. One factor that may make widespread message encryption more feasible is that email, instant messaging, and Internet telephony have quite similar trust models. Yet the definition of communication differs quite a bit between these technologies: in email "the message is the thing", and it is a discrete object in its own right; in telephony the focus is on the real-time flow of a conversation or session rather than discrete messages; and IM seems to hold a mediate position since it is centered on the rapid, back-and-forth exchange of text messages (which can be seen as messaging sessions). Another complicating factor is the wide range of contexts in which messaging technologies are used: everything from casual conversations in public chatrooms and social networking applications, through communications between businesses and customers, to mission-critical business-to-business applications such as supply chain management. Different audiences may have different needs with regard to messaging security and identity verification, resulting in varying demand for services such as trusted third parties and webs of trust. In the context of communication technologies, identity hints -- shared knowledge, conversational styles, voice tone, messaging patterns, vocabulary, and the like -- can often provide more useful information than key fingerprints, digital signatures, and other electronic artifacts, which are distant from the experience of most end users. To date, the checking of such identity hints is intuitive rather than programmatic.
Two potential research topics in authorization were discussed. First, a good deal of discussion centered around the use of whitelists and blacklists in authorization decision, but it was thought that research was necessary to examine the relative usefulness of each of the approaches fully. It was clear to the participants that blacklists can weed out known non-authorized senders, but do not stop "aggressive" unwanted senders because of the ease of simply obtaining a new identity. Whitelists can be useful for limiting messages to only those known to the recipient, but would require the use of some sort of introduction service in order to allow for messages from unknown parties. Participants also thought that there might be useful architectural work done in this area. The other potential research area was in recipient responses to authorization decisions. Upon making an authorization decision, recipients have to do two things: First, obviously the recipient must dispatch the message in some way either to deliver it or to deny it. But that decision will also have side effects back into the next set of authorization decisions the recipient may make. The decision may feed back into the reputation system, either "lauding" or "censuring" the sender of the message.
Another possible engineering task is defining a standardized representation for the definition and application of recipient message processing rules. Such an effort would extend existing work on the Sieve language within the IETF to incorporate some of the concepts discussed above. Discussion of token-based authorization focused on the concept of defining a means for establishing time-limited or usage-limited relationships for exchanging messages. The work would attempt to define the identity, generation, and use of tokens for authorization purposes. Most likely this is more of a research topic than an engineering topic. Work on recipient rules processing and token-based authentication may be related at a higher level of abstraction (we can call it "recipient authorization processing"). When combined with insights into authorization (see Sections 3.1 and 4.1), this may be an appropriate topic for further research.
a set of threads, and an activity as a collection of conversations and related resources. The discussion expanded the traditional notion of a thread as an ordered tree of messages. Conversations can collect together threads and have them be cross-media. Messages can potentially belong to more than one thread. Threads themselves might have subthreads. All of these topics require an architectural overview to be brought into focus. There is also engineering work that is already at a sufficient level of maturity to be undertaken on threads. Though there is certainly some simple threading work being done now with messaging, it is pretty much useful only for a unidirectional tree of messages in a single context. Engineering work needs to be done on identifiers that could used in threads that cross media. Additionally, there is likely work to be done for messages that may not be strictly ordered in a thread. The topics of "control panels" and automated introductions were deemed appropriate for further research. figured prominently in the transport discussion, was a need for some sort of identifier. In the transport case, identifiers are necessary on two levels. Identifiers are needed to mark the endpoints in message transport. As described in the discussion, there are many cases where a message could reasonably be delivered to different entities that might all correspond to a single person. Some sort of identifier to indicate the target person of the message, as well as identifiers for the different endpoints, are all required in order to get any traction in this area. In addition, identifiers are also required for the messages being transported, as well as their component parts. Certainly, the idea of transporting different parts of a message over different mechanisms requires the identification of the containing message so that re-assembly can occur at the receiving end. However,
identifying the entire package is also necessary for those cases where duplicate copies of a message might be sent using two different mechanisms: The receiving end needs to find out that it has already received a copy of the message through one mechanism and identify that another copy of the message is simply a duplicate. Workshop participants felt that, at the very least, a standard identifier syntax was a reasonable engineering work item that could be tackled. Though there exist some identifier mechanisms in current messaging protocols, none were designed to be used reliably across different transport environments or in multiple contexts. There is already a reasonable amount of engineering work done in the area of uniform resource identifiers (URI) that participants felt could be leveraged. Syntax would be required for identifiers of messages and their components as well as for identifiers of endpoint entities. Work on the general problem of identifier use might have some tractable engineering aspects, especially in the area of message part identifiers, but workshop participants felt that more of the work was ripe for research. The ability to identify endpoints as belonging to a single recipient, and to be able to distribute identifiers of those endpoints with information about delivery preferences, is certainly an area where research could be fruitful. Additionally, it would be worthwhile to explore the collection of identified message components transported through different media, while delivering to the correct end-recipient with duplicate removal and re-assembly. Package security was seen as an area for research. As described in Section 3.5, the possibility that different components of messages might travel over different media and need to be re-assembled at the recipient end breaks certain end-to-end security assumptions that are currently made. Participants felt that a worthwhile research goal would be to examine security mechanisms that could be used for such multi-component messages without sacrificing desirable security features. Finally, a more architectural topic was that of restartability. Most current message transports, in the face of links with reliability problems, will cancel and restart the transport of a message from the beginning. Though some mechanisms do exist for restart mid-session, they are not widely implemented, and they certainly can rarely be used across protocol boundaries. Some architectural guidance on restart mechanisms would be a useful addition.
Sections 3.5, 3.6, 4.5, and 4.6.
http://www.qualcomm.com/~presnick/ Peter Saint-Andre (Editor) Jabber Software Foundation P.O. Box 1641 Denver, CO 80201-1641 US Phone: +1 303 308 3282 EMail: firstname.lastname@example.org URI: http://www.jabber.org/people/stpeter.shtml
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).