[OTR-dev] OTR version 4 Draft #2

[Greg Troxel]

Ola Bini <list at olabini.se> writes:

>> > 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 see - that indeed makes sense.

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

It would be good to look at how all the various packaging systems are
dealing with the existing libotr.  In pkgsrc, it's libotr, version
4.1.1.  Some systems seem to have packages called libotr2 and libotr5,
or something like that, but I'm not sure why.

A big question is if you expect systems to allow building with an OTRv3
implementation that does v2 fallback.  I think you are heading for the
old library with the old filename and so versions, and a new library
with a different name (why ng, vs otr4, because 5 may happen, and ng2
gets awkward).  The old library will support v2 compat, but the new
library will only have v3 compat, using the old one in a way that
doesn't admit v2.  Is that what you mean?

The real problem is that many in-use clients are using old code.  That's
more of an intrinsic problem than an OTR problem, but OTR is coming
along for the ride.  I don't really know what to do, other than having
OTR supporters dig in and help the lagging projects along (or declare
some of them nonviable).  Given this, there's a tension between
requiring v3-or-newer only and allowing older things to work for a bit
longer in the hopes of getting them updated.  Otherwise, we risk two
clients that both "support OTR" not interworking, and developers
dropping OTR to avoid this.

Without thinking too much, I wonder if the best thing is to let the
protocol allow v2 (as "MAY") or not allow v2, augment libotr for OTRv4,
and have a build-time config to enable or not enable v2, leave it
enabled by default at first -- expecting packagers to take your default
-- and change the default when you are willing to abandon all systems
and users that are v2 only.  (If Adium's stable release did v3, I would
probably not have suggested this.)

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

Thanks.  It would be nice if thre were a dispassionate comparison
someplace.  In particular the usability issues are very hard (will
follow up separately on that).

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

That's unfortunate.  The removal of OTR from Conversations seemed
surprising and abrupt to me, but that's all I know.


Thanks for answering my questions so thoroughly.