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

[Peter Saint-Andre]

FYI. I'm working to get more Jabber developers interested in OTR. :)

-------- Original Message --------
Subject: [jdev] OTR (was: Re:  State of the XMPP Clients?)
Date: Wed, 17 Aug 2011 07:57:01 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: Jabber/XMPP software development list <jdev at jabber.org>
To: Jabber/XMPP software development list <jdev at jabber.org>

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.

Yes.

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

-- 
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________