search

ibauersachs / otr4j

Off-the-Record messaging library for Java
Apache License 2.0
65 stars 42 forks source link

integrating DATA_REQUEST and DATA_RESPONSE TLVs (aka OTRDATA) #16

Open eighthave opened 9 years ago

eighthave commented 9 years ago

I'm starting this issue as a place to track the integration of the OTRDATA features into the community otr4j version. OTRDATA is our internal name for two new OTR TLVs (DATA_REQUEST and DATA_RESPONSE) that allow for sending arbitrary files via in-band OTR. Guardian Project is also starting the process of getting these TLVs to be part of the OTR protocol officially. We have it implemented in our version of otr4j as part of ChatSecure (Android) and we use it as the basis for our rich messaging, so voice messages, images, etc. are sent via OTRDATA. Its been working for over a year now, and integrating it into otr4j means easy adoption for any app based on otr4j (including Jitsi, Xabber, Conversations, etc.).

We chose to implement data transfer in-band for a few reasons:

Here is the overview of the protocol: https://dev.guardianproject.info/projects/gibberbot/wiki/OTRDATA_Specifications

Right now, the first open question related to getting our implementation into the community otr4j is how to resolve the differences between the TLV handling between this otr4j and the ChatSecure otr4j. @devrandom, can you shed some light on that?

cobratbq commented 9 years ago

I noticed some of this when I was reading through the commit log a while back.

I also believe you explicitly disabled support for Type 8 TLV (extra symmetric key for out-of-band transfers over a separate channel) earlier. Is there a reason for not supporting this. Is there a risk/weakness there, or is it a convenience issue since separate channels may be hard to set up?

Danny

On 12/17/2014 11:59 AM, Hans-Christoph Steiner wrote:

I'm starting this issue as a place to track the integration of the OTRDATA features into the community otr4j version. OTRDATA is our internal name for two new OTR TLVs (|DATA_REQUEST| and |DATA_RESPONSE|) that allow for sending arbitrary files via in-band OTR. Guardian Project is also starting the process of getting these TLVs to be part of the OTR protocol officially. We have it implemented in our version of otr4j as part of ChatSecure (Android) and we use it as the basis for our rich messaging, so voice messages, images, etc. are sent via OTRDATA. Its been working for over a year now, and integrating it into otr4j means easy adoption for any app based on otr4j (including Jitsi, Xabber, Conversations, etc.).

We chose to implement data transfer in-band for a few reasons:

*

for small data transfers (e.g. voice messages, small images, etc), the
messages would be indistinguishable from standard text messages to
the network
observer

*

if an OTR session is established, then we are guaranteed a working,
bidirectional data transfer session, so many direct transfer
methods fail
because of NAT

*

other file transfer protocols for XMPP often negotiate a direct
connection
between the two parties, which is a privacy leak

*

OTRDATA works wherever there is OTR, so it'll work on top of many
protocols
(XMPP, AIM, IRC, etc).

Here is the overview of the protocol: https://dev.guardianproject.info/projects/gibberbot/wiki/OTRDATA_Specifications

Right now, the first open question related to getting our implementation into the community otr4j is how to resolve the differences between the TLV handling between this otr4j and the ChatSecure otr4j. @devrandom https://github.com/devrandom, can you shed some light on that?

— Reply to this email directly or view it on GitHub https://github.com/jitsi/otr4j/issues/16.

eighthave commented 9 years ago

as far as I know, the only reason why we have not included TLV8 is because no one had implemented it in otr4j at the time we were working on OTRDATA. We think the TLV8 model is not as private as OTRDATA, and relies on setting up and out-of-band connection, which has lots of its own problems. But its not so bad so that we don't want to support it.

maybe @devrandom has more to say on the topic, since he did most of the implementation of OTRDATA.

eighthave commented 9 years ago

Since we have OTRDATA working in ChatSecure, I'm taking this opportunity to think about what the OTRDATA API should look like in otr4j. I would like to make it as simple and as standardized as possible so that it will be easy to add to apps.

I think I finally have a grasp on the whole OTRDATA stack. Right now, a lot of the OTRDATA API in ChatSecure is in the ChatSecure code. ChatSecure's otr4j is just providing the very lowest level of support, providing ChatSecure with the raw TLVs. I think this API should not expose TLVs at all. I'm currently thinking otr4j should provide a dead simple interface for sending/receiving files.

Since it is structured like HTTP GET/PUT, perhaps we should model Apache's HTTP Client API, and have classes for GET and PUT.

eighthave commented 9 years ago

@chrisballinger and I just chatted about this some more, he showed me his OTRKit interface: https://github.com/ChatSecure/OTRKit/blob/otrdata/OTRKit/OTRData/OTRDataHandler.h

He also pointed me towards this ChatSecure class, where the meat of OTRDATA is: https://github.com/guardianproject/ChatSecureAndroid/blob/master/src/info/guardianproject/otr/OtrDataHandler.java

I like Chris' approach with a very simple API for sending and receiving files. We can start with that for now, and see where it goes from there. I'd like to support streams, for example, that have a footer with the size and hash, rather than a header. Then when someone starts recording a push-to-talk message, the OFFER can go out immediately, and the other side can immediately reply with a GET and start getting the audio stream and play it as it comes in. With the current file-based API, the voice file won't even be OFFERed until it is complete.