Re: CPIM changes and XMPP

John-

As somebody who is familiar with XMPP, IM and has had experience 
deploying solutions in various business and consumer environments, I'll 
try to address your concerns below.

 > On another subject, I just read drafts from the Jabber Software
 > Foundation on the eXtensible Messaging and Presence Protocol (XMPP).
 > The first issue that that stood out to me is that no request is
 > time-stamped in this protocol!  Replay attacks seem to be of no
 > concern to the authors.

I'm not convinced that this particular problem is one we need to worry 
about in consumer IM. If I'm just chatting with a friend, and somebody 
decides to take a packet and resend it across the line, so that I get a 
message twice, I can probably figure out that something fishy is up by 
the context of the conversation. I could even ask my friend why he 
decided to say "Hello" twice. I'm just not convinced that this is 
something that is needed in a consumer IM solution.

Business solutions are different, especially when we start talking about
implementing applications on top of these protocols, something which 
XMPP is well suited for. But one of the strengths of XMPP makes this 
almost a non-issue. Since XMPP is XML-based, and easily extensible, 
there is nothing preventing anybody from defining an extension to the 
protocol by way of a new element and new namespace. My application will, 
of course, react appropriately if this element isn't present, or the 
data is suspect. FYI- your mention of this potential issue has lead to 
discussions of work on a JEP [1] in this area that could be integrated 
into the XMPP draft, or a related draft, in the future.

 > XMPP's support for end-to-end security appears to be an afterthought.
 > I found no end-to-end security for presence information or
 > subscription requests.  Instant messages can be encrypted using PGP,
 > as described in Appendix C of the XMPP Core document.  Because XML
 > syntax is used thoughout the protocol, encrypted data is encoded in
 > ASCII.  The protocol does not appear to be able to correctly interpret
 > signed or encrypted messages in the CPIM-MSG format.  My guess is the
 > authors think that security needs can be satisfied using weak
 > techniques such as hop-by-hop encryption, which require that a user
 > trust all servers that route the user's messages.

Again, I'm not certain why the protocol needs to address this particular
issue, and not rely on existing technology. PGP/OpenPGP is an existing
solution, that is designed to be secure by people who have expertise in 
that area. XMPP is a protocol for transmitting presence and messages 
across a wire, designed by people who have expertise in that area. A 
solution based on combining this two technologies makes sense. RFC2821 
and RFC2822 don't require support for interoperable exchange of 
encrypted messages, but instead implementers of those protocols have 
found ways to layer security on top of open and easy to use protocols. 
The XMPP authors have even taken the time to outline the details on how 
to support OpenPGP in XMPP in Appendix C of xmpp-core-02 [2].

In which way is XMPP not able to correctly interpret signed or encrypted 
messages in CPIM-MSG format? There are various ways that opaque payloads 
can be carried in XML, and the XMPP protocol already has one example of 
this in its ability to carry SASL blobs within the protocol. This 
particular issue seems almost like a non-starter, while there aren't 
specific provisions for dealing with MIME data, currently, the 
flexibility of an XML-based protocol should make this merely a clerical 
exercise, should the CPIM-MSG format ever be finalized.

 > What is the relation of XMPP to the IMPP working group?

I believe the relationship is outlined in the XMPP charter.

Cheers,

bs.

Links:
[1] http://www.jabber.org/jeps/
[2] http://www.jabber.org/ietf/




  [reminder: [email protected] for non-technical discussions, please]