[guardian-dev] OTRDATA draft specifications

Dev Random c1.devrandom at niftybox.net
Wed Oct 16 16:54:15 EDT 2013


On 10/13/2013 02:35 PM, Kevin Steen wrote:
> On 13/10/13 20:44, Dev Random wrote:
>> Here is a preliminary draft of the Guardian OTRDATA specifications.  The
>> purpose of this specification is to standardize data transfer and
>> request/response oriented applications inside the encrypted OTR channel.
>>
>> https://dev.guardianproject.info/projects/gibberbot/wiki/OTRDATA_Specifications
> I may be misunderstanding the OTR specfication, but it seems like it
> requires acknowledgement of every packet, with no more than 2 packets
> allowed to be unacknowledged at any point?

There's no proactive acknowledgement at all in the protocol so I don't
think this concern applies.  Note that there is an implicit
acknowledgement as messages are sent and keys are rotated.

> On a high-latency network connection (e.g. Both ends using WiFi) I think
> this will seriously limit the transfer rate achievable and effectively
> make file transfers impractical - especially when combined with the
> base-64 encoding drastically reducing the available bandwidth. The TCP
> protocol can only utilise the full bandwidth of a link when it can
> expand its window and have many packets in-flight.

base-64 only reduces bandwidth by 25% (8 bit -> 6 bit).  We are
currently using a request queue of length 5, 32KB packets and getting
pretty respectable throughput.

>
> That said, I believe the specification is still extremely useful for
> allowing smaller data exchanges between compatible plugins on each end.
>
> Three things I think should be added to the specification:
> 1. Explicitly list the allowed Response codes, even if just to reference
> the HTTP specification.

Agreed.

> 2. Provide a way to request a list of available remote applications,
> rather than having to enumerate each one and check for a 404 response.
> e.g. GET chatsecure:/meta/applications

Also agreed.

> 3. Document a standard location for reserving application identifiers to
> guarantee uniqueness & interoperability (e.g. A wiki page somewhere) -
> the android method of using domain names fails as time passes and people
> move domains. Perhaps recommend that plugin writers generate and
> document a GUID?

Good point.  For now, I would use the wiki page the spec is written on
to record identifiers.  Perhaps people should also provide a PGP
fingerprint to be associated with the ID for future authentication of
the "ownership" of the ID.

>
> The use case I'm thinking of is to use the OTR session between multiple
> devices to sync data from multiple applications (e.g. Contacts,
> bookmarks, etc.)

Syncing between multiple presences of the same user is definitely a very
interesting use case.

>
> -Kevin



More information about the Guardian-dev mailing list