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

[Ximin Luo]

(I've switched to a new email address)

On 22/01/14 01:27, Guy K. Kloss wrote:
> Hi all,
> 
> so, there's been lots of talk recently about mpOTR (or whatever will
> come out of it, maybe in the form of some kind of mpENC ...). Many posts
> were deferring to face-to-face discussions at the recent RWC [1].
> 
> As somebody who didn't attend RWC, and only read some interesting record
> snap shot of opinions on PiratePad [1], I'm keen to find out more about
> what the state of the discussion around mpOTR is. Have there been more
> meetings? Maybe some more meeting notes? Has somebody aggregated some
> kind of plan or consensus for further work?
> 

Hey Guy, I think you missed the final pad from the last day:

http://piratepad.net/GMplxYhLSA

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.

Away from the overall mpOTR discussions, I spent a lot of time on the side talking about forward-secrecy ratchets with Trevor. We also talked about the advantages and disadvantages of a pair-based system. (This is opposed to a group-based system that most others are thinking about). We and some others think it would be worth pursuing this further, with the understanding that this would not scale to massive groups. Despite this, the advantages are:

- strong security properties (inc. deniability) can be implemented in a much simpler way
- there is individual control over group decisions like join/part/expiry
- the overhead can be made independent of the message size, so only linear in the number of participants
- no need for complex key exchanges, easier to make work for the high-latency case (inc. store-and-forward)

Additionally, doing work in this area lets us explore issues like transcript consistency and the expiry of participants in more depth, without worrying too much about group key exchanges. The lessons we'll learn will probably be useful for group-based approaches too.

To be clear, only a subset of people support this direction, but I think it can lead to somewhere concrete much faster than a fully-generalised mpOTR strategy will.

I've started writing up more technical notes but they're not ready for public consumption yet. The general strategy is to extend a ratchet that is aware of message partial-ordering to multiple parties, then add a join/part/expiry protocol on top of this. Note, I'm not just "going in blind", I have thought about the latter before already, in a way that fits into a partial-ordering model.

(I'd be happy to talk more technical details over IM; this email address is also an XMPP address.)

> I really liked the kind of momentum that could be injected by Nadim's
> shout out recently. But it got a bit quite after a whole bunch of
> responses to that call for participation. So some kind of feedback for
> those not present at RWC or 30C3 [2] would be highly appreciated.
> 
> After reading [1], I thought that a solution to the ordering criteria in
> presence of potential clock skew could be to use vector timestamps [3]
> complemented by a common agreed rule to sort messages that have to be
> considered concurrent according to the vector timestamps. And I think
> this type of ordering could be sufficient, but that of course largely
> depends on how the communication protocol and it's constraints will be
> designed.
> 
> Anyway, I'm happy to hear and/or discuss things, just need some kind of
> input through the list.
> 
> Guy
> 
> 
> [1] http://piratepad.net/AV5fQQf72U
> [2] http://piratepad.net/xCsrJ1xFUE
> [3] https://en.wikipedia.org/wiki/Vector_clock
> 
> 

-- 
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/11939d34/attachment.pgp>