[jdev] OTR (was: Re: State of the XMPP Clients?)

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 17 13:57:01 UTC 2011

On 8/16/11 7:08 PM, Andreas Monitzer wrote:
> On Dienstag, 16. August 2011 at 23:30, Peter Saint-Andre wrote:
>> Don't forget OTR, too (I might be working on an Internet-Draft
>> about that with some of the OTR folks):
>> http://www.cypherpunks.ca/otr/
> I know about OTR, but I don't like the standard. Due to its
> transport-independence, it doesn't integrate at all into XMPP. For
> example, there's no discovery for it. The client determines support
> at the other side by sending encrypted text and waiting whether a
> "wtf" by an irritated/confused human or a proper OTR response comes
> back.

Yes, that's an ugly hack, which is needed to work around the lack of 
discovery protocols in systems like AIM and Yahoo. However, in XMPP we 
have ways to discover feature support (service discovery and entity 
capabilities), so it seems to me that we can define an XMPP feature for 
OTR (properly versioned because OTRv3 is on the way) and simply ignore 
the hacky text stuff.

> It also takes over the regular<body/>-tag for its binary data
> instead of using a proper separate tag with its own namespace (like
> xhtml-im).

On this point, I think we can work with the OTR team to define an XMPP 
binding in OTRv3 or (more likely) OTRv4. The XMPP binding would be more 
consistent with the Tao of Jabber, and if you're using AIM or Yahoo or 
whatever then you'd default to stuffing all the data in the message 
body. The XMPP binding would also enable us to perform whole-stanza 
encryption for all stanza types (think Jingle negotiation and such), 
instead of just the <body/> element of the <message/> stanza.

> Further, the library's LGPL license is incompatible with Apple's App
> Store, and so I'd have to implement it on my own…

Multiple implementations might be a good thing. :) The XSF might even be 
able to provide funding for folks to work on a common library (BSD or 
MIT licensed) that can be used by a wide variety of clients.

> At least the spec
> seems to be fairly detailed.


More than that, OTR just works [tm]. We've had debates for many years 
about PGP, S/MIME, SIGMA-based encrypted sessions, XTLS, etc. But for as 
long as we've been having these interminable discussions, OTR has 
quietly been working in the real world -- field tested by thousands of 
users in a wide variety of clients, and seemingly resistant to attacks.

Instead of trying to invent something new, why don't we use something 
that has plenty of running code behind it?


Peter Saint-Andre

More information about the JDev mailing list