[messaging] Secure messaging over insecure chat frameworks

[Andy Isaacson]

On Tue, Feb 11, 2014 at 10:01:19PM +0000, George Kadianakis wrote:
> While thinking of secure overlay (on top of IRC/XMPP/etc.) messaging
> protocols, I started pondering the security implications that the
> underlying chat frameworks have on them.
> 
> For example, when we think of a secure multiparty messaging protocol
> over IRC, ...

[snip a bunch of extremely relevant observations]

I have been thinking a similar thought, which I've phrased as follows.

It is "easy" to see how 2-party-OTR layers on top of IM -- in fact, on
top of any point-to-point messaging protocol.  OTR on AIM!  OTR on ICQ!
OTR on XMPP!  OTR on Twitter!  OTR on IRC!  OTR on MMS!  Once one sees
that encapsulating a channel is possible, the encapsulation "follows
naturally" and the semantic mismatch is fairly low.

It is *not* "easy" to see how mpOTR layers on top of $GROUPCHAT.  On
considering the details, it seems like no matter how you push it, the
semantic mismatch remains sizeable.

Why is that?

Some possible reasons --

 - group semantics are "more different" than IM semantics.

 - group chat is inherently more difficult than 2-party chat.

 - group chat has more design flexibility, leading to different
   semantics, leading to mismatch when the layered-on-top mpOTR protocol
   tries to provide semantics that don't map to the underlying system.

 - group chat *has* more semantic meaning embedded in the underlying
   protocol, some of which has significant mismatch to the layered
   protocol.

I think the last one is my best effort, and it has meaning in a bunch of
different areas, but one of George's points makes it very succinctly:

> * Any user of the IRC server can attempt to /join the "secure"
>   channel. You can block this by password-protecting the channel, or
>   making it invite-only.
> 
>   Each messaging framework has different ways of blocking unexpected
>   joins: IRC has the +k channel mode, XMPP MUCs have the <password>
>   field in the presence stanza. Of course in both cases, the server
>   knows the password of the channel.

"What does it *mean* for Carol to join the group currently containing
Alice and Bob?" is the core question in the above.  It is entirely
possible for a protocol layering to give *different* meanings to the
same action at different layers of the protocol.  This is a kind of
abstraction violation.  These violations happen in any protocol
layering, but there seem to be a *lot* of opportunities for mismatch
between mpOTR and "group chat transport" candidates.


A slightly related observation -- one can easily imagine
 - OTR-over-XMPP
 - to a server-server proxy 
 - bridged to AIM
 - received by OTR-over-AIM

I believe (though I haven't verified) that the OTR implementations would
communicate this way just fine.

Now imagine trying to build a similar bridge connecting an
mpOTR-over-XMPP-group with mpOTR-over-IRC, with multiple clients on each
transport.  I have a fairly hard time imagining how to implement that
system.  (But maybe I just don't have a good enough imagination...)

-andy