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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
