[OTR-dev] OTR version 4 Draft #2

[Ola Bini]

Hi,

I'm Ola - one of the members of the OTRv4 team. I would like to
clarify and answer a few of your questions in the following email!
Hope it's helpful!

> > I'm in principle fine with dropping v2 support.  I wouldn't mind a quick
> > look-around at what OTR implementations still don't support v3, though.
> > pidgin-otr does, of course.  What about Adium?  Others?
>
> By dropping support, is this about removing it from libotr?   I am not
> quite following standard vs reference implementation vs ?
Actually, the way we have thought about this is from the specification
standpoint. Our current OTRv4 has fallback to OTRv3 - but it doesn't
include any facility for falling back to v2. We followed the pattern
that the OTRv3 spec used for this.

I would also argue that removing support for v2 is about time - v3
adds several things that are quite important, and there are several
parameters in v2 that are too small for my comfort.

About implementations - we are currently working on a library called
libotr-ng - which will be the production level implementation of
OTRv4. It does _not_ contain full support for OTRv3 - instead, it
links the old libotr implementation for that functionality. Hope this
clarifies things!

>   With pidgin and adium, I have had lost OTR messages, apparently from
>   one side using keys the other side has lost due to restart.  I hope v4
>   has systematic mitigation for this.
I'm wondering if you could create a new email chain for this so we can
discuss it more in depth - v4 does not currently have any specific
support for this, and there are good reasons for it - but let's move
that to a new thread?

>   Conversations has dropped OTR support, leaving OMEMO.  I am unclear on
>   the relative merits of OMEMO and OTR, but I've been an OTR user for a
>   really long time (<= 2005), so I have a pro-OTR cultural bias and
>   would like to see it succeed.  I wonder if anyone for otr-land has
>   engaged Conversations about this.
The situation between OTR and OMEMO is a bit complicated. Short story
- from my perspective: OTR and OMEMO have quite different viewpoints
and perspectives on several things, including supporting networks
other than XMPP, support for SMP, stronger AKE's and several other
aspects. We, in the OTRv4 team, believe that the choices we have made
in the design of v4 will lead to a significantly stronger protocol,
both from a purely cryptographic perspective, but also from a
usability and deployability perspective. Not speaking for the OMEMO
team, but my impression is that they disagree with this belief.

There have been interactions with people involved in Conversations and
OMEMO at several times. I would characterize those interactions as not
being super constructive.

Cheers
-- 
 Ola Bini (https://olabini.se)

 "Yields falsehood when quined" yields falsehood when quined.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20180509/552aae5b/attachment.sig>