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.
4. Recommendations
4.1. Authorization
The one clearly desired engineering project that came out of the
authorization discussion was a distributed reputation service. It
was agreed that whatever else needed to be done in regard to
authorization of messages, at some point the recipient of the message
would want to be able to check the reputation of the sender of the
message. This is especially useful in the case of senders with whom
the recipient has no prior experience; i.e., using a reputation
service as a way to get an "introduction to a stranger". There was
clearly a need for this reputation service to be decentralized;
though a single centralized reputation service can be useful in some
contexts, it does not scale to an Internet-wide service.
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.
4.2. Multiple Communication Channels
Several interesting and potentially useful ideas were discussed
during the session, which the participants worked to transform into
research or engineering tasks, as appropriate.
In the area of contact information management, the workshop
participants identified a possible engineering task to define a
service that publishes contact information such as availability,
capabilities, channel addresses (routing information), preferences,
and policies. While aspects of this work have been attempted
previously within the IETF (with varying degrees of success), there
remain many potential benefits with regard to managing business-to-
business and business-to-customer relationships.
The problem of suppressing redundant messages is becoming more
important as the use of multiple messaging channels becomes the rule
for most Internet users, and as users become accustomed to receiving
notifications in one channel of communications received in another
channel. Unfortunately, there are essentially no standards for
cross-referencing and linking of messages across channels; standards
work in this area may be appropriate.
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.
4.3. Negotiation
Discussion in the area of negotiation resulted mostly in research-
oriented output. The session felt that participants in a
conversation would require some sort of rendezvous mechanism during
which the parameters of the conversation would be negotiated. To
facilitate this, a "conversation identifier" would be needed so that
participants could identify the conversation that they wished to
participate in. In addition, there are at least five dimensions
along which a conversation negotiation may occur:
o The participants in the conversation
o The topic for the conversation
o The scheduling and priority parameters
o The mechanism used for the conversation
o The capabilities of the participants
o The logistical details of the conversation
Research into how to communicate these different parameters may prove
useful, as may research into the relationship between the concepts of
negotiation, rendezvous, and conversation.
4.4. User Control
A clear architectural topic to come out of the user control
discussion was work on activities, conversations, and threads. In
the course of the discussion, the user’s ability to organize messages
into threads became a focus. The participants got some start on
defining threads as a semi-ordered set of messages, a conversation as
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.
4.5. Message Transport
A central research topic that came out of the transport session was
that of multiple transports. It was felt that much research could be
done on the idea of transporting pieces of messages over separate
transport media in order to get the message to its final destination.
Especially in some high-latency, low-bandwidth environments, the
ability to run parallel transports with different parts of messages
could be extremely advantageous. The hard work in this area is
re-associating all of the pieces in a timely manner, and identifying
the single destination of the message when addressing will involve
multiple media.
A common theme that arose in several of the discussions (including
user control and message unification), but that 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.
4.6. Identity Hints and Key Distribution
It would be helpful to develop Internet-wide services to publish and
retrieve keying material. One possible solution is to build such a
service into Secure DNS, perhaps as an engineering item in an
existing working group. However, care is needed since that would
significantly increase the size and scope of DNS. A more research-
oriented approach would be to investigate the feasibility of building
Internet-wide key distribution services outside of DNS. In doing so,
it is important to keep in mind that the problem of distribution is
separate from the problem of enrollment, and that name subordination
(control over what entities are allowed to create sub-domains)
remains necessary.
Research may be needed to define the different audiences for message
security. For example, users of consumer-oriented messaging services
on the open Internet may not generally be willing or able to install
new trusted roots in messaging client software, which may hamper the
use of security technologies between businesses and customers. By
contrast, within a single organization it may be possible to deploy
new trusted roots more widely, since (theoretically) all of the
organization’s computing infrastructure is under the centralized
control.
In defining security frameworks for messaging, it would be helpful to
specify more clearly the similarities and differences among various
messaging technologies with regard to trust models and messaging
metaphors (e.g., stand-alone messages in email, discrete
conversations in telephony, messaging sessions in instant messaging).
The implications of these trust models and messaging metaphors for
communications security have not been widely explored.
5. Security Considerations
Security is discussed in several sections of this document,
especially Sections 3.5, 3.6, 4.5, and 4.6.
6. Acknowledgements
The IAB would like to thank QUALCOMM Incorporated for their
sponsorship of the meeting rooms and refreshments.
The editors would like to thank all of the workshop participants.
Eric Allman, Ted Hardie, and Cullen Jennings took helpful notes,
which eased the task of writing this document.
Appendix A. Participants
Eric Allman
Nathaniel Borenstein
Ben Campbell
Dave Crocker
Leslie Daigle
Mark Day
Mark Crispin
Steve Dorner
Lisa Dusseault
Kevin Fall
Ned Freed
Randy Gellens
Larry Greenfield
Ted Hardie
Joe Hildebrand
Paul Hoffman
Steve Hole
Scott Hollenbeck
Russ Housley
Cullen Jennings
Hisham Khartabil
John Klensin
John Levine
Rohan Mahy
Alexey Melnikov
Jon Peterson
Blake Ramsdell
Pete Resnick
Jonathan Rosenberg
Peter Saint-Andre
Greg Vaudreuil
Appendix B. Pre-Workshop Papers
The topic papers circulated before the workshop were as follows:
Calendaring Integration (Nathaniel Borenstein)
Channel Security (Russ Housley)
Collaborative Authoring (Lisa Dusseault)
Consent-Based Messaging (John Klensin)
Content Security (Blake Ramsdell)
Event Notifications (Joe Hildebrand)
Extended Messaging Services (Dave Crocker)
Group Messaging (Peter Saint-Andre)
Identity and Reputation (John Levine)
Instant Messaging and Presence Issues in Messaging (Ben Campbell)
Large Email Environments (Eric Allman)
Mail/News/Blog Convergence (Larry Greenfield)
Messaging and Spam (Cullen Jennings)
Messaging Metaphors (Ted Hardie)
MUA/MDA, MUA/MSA, and MUA/Message-Store Interaction (Mark Crispin)
Presence for Consent-Based Messaging (Jon Peterson)
Rich Payloads (Steve Hole)
Session-Oriented Messaging (Rohan Mahy)
Spam Expectations for Mobile Devices (Greg Vaudreuil)
Communication in Difficult-to-Reach Networks (Kevin Fall)
Store-and-Forward Needs for IM (Hisham Khartabil)
Syndication (Paul Hoffman)
Transport Security (Alexey Melnikov)
VoIP Peering and Messaging (Jonathan Rosenberg)
Webmail, MMS, and Mobile Email (Randy Gellens)
Authors’ Addresses
Peter W. Resnick (Editor)
Internet Architecture Board
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
US
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: 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: stpeter@jabber.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
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).