Re: [xmpp] Self Introduction

["Matt Miller (mamille2)" <[e-mail]>]

[ "switching" venue for wider security review ]
[ context for XMPP WG: http://mail.jabber.org/pipermail/standards/2013-February/027167.html ]

Hello Jon,

I find this work interesting, but I also have some concerns here.  I don't expect definitive answers to all of them, but think they're worth discussion to help the working group choose a path forward.

I think there is an additional application requirement concern regarding multiple resources.  The XSF has technologies in development to multiplex chat conversations, namely [CARBONS].  I'm not sure that E2E-REQ calls it out, but it will be an important consideration for the very near term.  I'm curious how yabasta can accommodate things like carbons without in a user-transparent manner.

from your response on [e-mail], an effective fork of OTR doesn't exactly meet the (existing) XMPP WG charter requirement.  I'm not saying that's necessarily bad, but it is something to consider as we move forward.  Not that I have much moral authority here with [XMPP-E2E] (-;  However, my draft is based on a technology with a lot of momentum behind it, so it is likely to be "widely deployed and implemented" by the time we get completely done.

One of the big detractions from RFC3923 was the multiple paths followed.  It looks like this duplicates that, and not in a necessarily better route.  Various other attempts at this space have tried to deal with a single path (whole stanzas) to eliminate the complexity.  It is nice there is an existing implementation, but is there enough value in multiple paths to continue down that road?

I have some concerns that there are a lot of cryptographic primitives here, and it doesn't look very negotiable for those primitives.  I'm hesitant to have this much specialized work happen in a group that does not have the expertise.  Would it be possible (and worthwhile) to separate this more, and possibly push the primitives through the security area?

Finally, given your original post, seeing the word "forgeability" as a feature makes me personally very nervous.  I don't claim to be an expert, or much more than a erstwhile enthusiast, but I have a hard time seeing this being a good idea in general.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.

[CARBONS] XEP-0280: Message Carbons < http://xmpp.org/extensions/xep-0280.html >
[XMPP-E2E] End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) < http://tools.ietf.org/html/draft-miller-xmpp-e2e-05 >

On Feb 26, 2013, at 7:35 AM, Jon Kristensen <[e-mail]> wrote:

> Hello, everyone!
> 
> I would like to briefly introduce myself to the members of this mailing list, and to inform you of my interest of contributing to the standardization of the use of the Off-the-Record protocol with XMPP.
> 
> My relevant past experience includes being one of the co-authors of Pontarius XMPP[1], a client XMPP library for Haskell, as well as the prototyping of a OTR-based (but (so far) OTR-incompatible) JavaScript application currently called Yabasta[2].
> 
> In the process of prototyping Yabasta, I have "designed" an OTR-like protocol[3] that, while based on OTR, differs from OTR in a number of ways. Most importantly, the OTR messages (be it the authenticated key exchange, the protected payloads, or the Socialist Millionaire's Protocol) are expressed with XML instead of with a binary encoding. Also, the prime numbers used are negotiatable, and any XML payloads can be protected (not just message bodies). (I never meant to go "Not invented here" in regards to OTR: my intention was simply to make the protocol easier to understand and to implement, more flexible, and better suitable for XMPP. However, I have since then that straying so far from OTR might not have been the best idea.)
> 
> Please don't hesitate to contact me if you are working on anything related to the above, or if you have any other questions or concerns.
> 
> Warm regards,
> Jon Kristensen
> 
> [1]: http://hackage.haskell.org/package/pontarius-xmpp/
> [2]: https://yabasta.com/
> [3]: https://github.com/jonkri/yabasta-protocol/
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp