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

[Guy K. Kloss]

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.

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.).

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.

> 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:

Personally, I'd take the position here on group-based systems ...

> - 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)

I can see those advantages, but these are the immediate disadvantages I
can see:

* Key agreement, though easier conceptually, involves many more message
  exchanges. If everyone needs to exchange keys with everyone, we're in
  an O(n^2) situation. If we'd use (just for simplicity reason) a
  Group Diffie-Hellman key agreement, we're already in the O(n) range
  of message exchanges. And I believe that message exchange latencies
  can play a major role in a secure group chat protocol.

* There's the need to ensure that all participants will receive *the
  same* message, when encrypted/signed for each participant
  individually.

As for the first point, I've started working on a simple GDH
implementation, which should be quite suitable for groups in the order
of magnitude around 10 users, and getting more difficult around 100. To
keep messages small and computational overhead small, I'm currently
doing Curve25519-based scalar multiplication chains rather than
classical DH exponentiation.

As a logical progression from there Ed25519 ephemeral signatures would
work well in this scenario as opposed to doing vanilla DSA or RSA.
Having said that, I think it'd still be a good idea to keep using the
long term DSA secret of OTR for the initial participant authentication.

> 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.

For sure!

> 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.

Agreed. As I had indicated in an earlier mail, I'm also looking at an
"evolutionary" approach, which will not do the full mpOTR monty off the
bat, but start with group encryption first.

> 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.

Really looking forward to that.

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

Just added you to my messenger. I'm xemacs at jabber.org.

Guy

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