Re: [xmpp] Self Introduction

[Jon Kristensen <[e-mail]>]

Hi Matt!

I just realized that there is another thing about myself that I should 
probably bring up. My overall vision is to generalize on the OTR 
protocol and build systems that exposes as little information as 
possible to intermediate entities, including the XMPP server. In fact, 
I'm opposed to the concepts of cloud computing and software as a service 
as a whole. I'm aiming to build client solutions that are independently 
capable and privacy-aware. In effect, I consider the XMPP server 
primarily a proxy, authenticator, and stanza router. This renders quite 
a few XMPP extensions incompatible with what I'm trying to do.

With this idea in mind, I will value properties (like repudiability and 
forward secrecy) that may not be valued by other developers. We may very 
well find that the properties that makes an end-to-end security protocol 
perfect for me, will make it overly complex for others. On the other 
hand, we may also find that the features that I value could be 
interesting for other implementations as well. Either way, I look 
forward to the discussions, and hope that there is room for my vision 
within the XMPP community.

Anyway...

In the case of OTR/Yabasta, the secure channels are negotiated between 
only two resources (and, what's worse, the symmetric key is continously 
changing in order to allow for forward secrecy), so no other client 
would be able to decrypt the forwarded message. Thus, [CARBONS] would 
seem to be incompatible with the current version of OTR/Yabasta. I'm 
currently not sure of whether or not it would be possible to extend 
OTR/Yabasta with transparent support for multiple resources. I will take 
a look at that.

The authenticated key exchange of OTR "mathematically" requires four 
messages (six if we want confirmation by empty IQ result stanzas). This 
is unfortunate, but seems necessary for the Diffie-Hellman key exchange 
(allowing for forward secrecy) as well as the hiding of the long-term 
public keys from a passive attacker. I'm looking into ways of making 
this more effective.

There's not that much difference between OTR and Yabasta from a 
cryptography point of view, so it should not be difficult to review its 
security.

You also mentioned forgeability. I'm currently investigating what the 
benefits are of this feature, and I will present my findings when I'm done.

Thanks for your reply!

Best,
Jon Kristensen

On 02/27/2013 08:11 PM, Matt Miller (mamille2) wrote:
> [ "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