[OTR-dev] Fwd: [jdev] OTR

[Nathan of Guardian]

Can you let them know that the use of the "Whitespace Tag" is indeed a
way to support discovery without causing the WTF moment described below?
This is something we support in Gibberbot on Android.

Whitespace Tag:

    There is an OTR_MESSAGE_TAG, which is a 24-byte string of whitespace
    that clients can optionally append to (or insert in) messages to
    unobtrusively indicate that they understand the OTR protocol.  The
    string is as follows (in C notation):

	\x20\x09\x20\x20\x09\x09\x09\x09
	\x20\x09\x20\x09\x20\x09\x20\x20
	\x20\x09\x20\x09\x20\x20\x09\x20

    [This is the bit pattern of the string "OTR" as expressed in spaces and
    tabs.]




On 08/17/2011 10:11 AM, Peter Saint-Andre wrote:
> 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
>