[OTR-dev] mpOTR and the road ahead ...?

[Ximin Luo]

On 22/01/14 03:44, Guy K. Kloss wrote:
> Hi Ximin,
> 
> On 22/01/14 15:28, Ximin Luo wrote:
>> Hey Guy, I think you missed the final pad from the last day:
>>
>> http://piratepad.net/GMplxYhLSA
> 
> Indeed. I suppose it's not easy to come by this information if one is
> not present at the conference ... thanks for mailing it through.
> 
>> It's a list of issues that mpOTR / smpchat would need to address,
>> and potential ways of solving each issue. I missed this part of the
>> meeting, but I hear that the next step is to pick a subset of the
>> candidate-solutions that we should try to accomplish.
> 
> Yes, I think the main issue is that people know what OTR is, and they
> want to "stretch out" the use case according to need. Unfortunately the
> use cases are not all compatible with all ideas on the wish list.
> 
> It seems like particularly conflicting is the desire to stretch it into
> the direction of being able to handle asynchronisity (for the OTR as
> well as mpOTR case), which does not work well with e. g. key agreement
> and ephemeral keys.
> 
> For these reasons, I guess it's first of all important to sub-select the
> boundary conditions for one (or several) usage scenarios. If certain
> mechanisms don't work for a scenario, then (optional) alternatives may
> need to be found, while maybe other mechanisms still work.
> 

I agree it's important to be clear what properties you are looking for in a system, so that people with different systems in mind can build them separately without coming into unnecessary conflict.

Right, it's not clear how to achieve asynchronisity and group key exchanges. That was indeed one of the motivations driving me down the pair-based path. For the two-party case though, I believe WhisperSystems have a good working solution for TextSecure - actually their ideas inspired a lot of what I was talking about in the pair-based system.

> As for my/ourselves, we've been looking at OTR (which has become a
> de-facto standard, much more than its alternatives), because it just did
> what it did, without trying to be the all satisfying solution (which is
> often the death of great ideas when taken to a consortium). So, the most
> important thing that *we* are looking at is just to do what the the
> existing OTR and the name of mpOTR imply: A system that can be used in
> synchronous mode to secure live group communication channels.
> 
> As far as having had a look at the two extensive list of issues and
> discussions on the PiratePads, I must say that many of these issues may
> need a solution through policy, and not quite by protocol implementation
> (e. g. on who to join or kick, when is a user's session to be considered
> stale and the user will be removed from the group, etc.).
> 

I agree, policy is a large part of it and some of us made this point too; I hope it's been preserved in the pad. For example, one option for expiry:

- each guest sets a "propose to force-part a guest if inactive for x seconds"
- each guest sets a "ignore/reject proposals shorter than y seconds", as a protection against rogue proposers

To simplify things, the developer can pick default values for these, perhaps even hard-code it. In all cases though, the protocol still needs to handle the propose/agree messages.

(This is just an example, I don't mean for this to get too deep. There are other options like automatic implicit expiry with its own pros/cons.)

> So one may just go and start on several basic conceptual decisions that
> build on top of "what people know from OTR", and leave out other issues
> to be decided or worked on later.
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20140122/d3dc0bd6/attachment.pgp>