[messaging] Secure messaging over insecure chat frameworks
adi at hexapodia.org
Tue Feb 11 14:33:52 PST 2014
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
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
- 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...)
More information about the Messaging