Hi Andy! Thank you for your statement.
I think it's important to stress, that your proposed "ODR" is a good
compromise between using libsignal and using Olm, since it enables both
libraries to be used (with some modifications). This is way better than
changing the whole base library, since you can just fork libsignal and
olm and make the required changes. Clients can then use those libraries
without having to reinvent the wheel.
Also I aggree that it is quite important to have the XEP updated so that
there is less confusion about it using Olm.
Vanitasvitae
Am 24.05.2017 um 22:55 schrieb Andreas Straub:
> Hey all,
>
> it has been brought to my attention that my recent silence on this
> matter is being perceived as "unresponsiveness", so I guess I should
> clear up a few things.
>
> I haven't commented on this issue in a while because I don't feel I
> have anything significant to add at this point. Most of the arguments
> have been made (by me and others) months ago, and nothing significant
> has changed. I generally try to refrain from repeating things others
> have already said, especially on mailing lists, and I guess I just
> wasn't aware that that's exactly what the XSF process required me to
> do in this case. Sorry about that. So let me try to sum up where we
> stand right now.
>
> First, for a bit of additional background, I suppose I should clear up
> the misconception that (under my proposed changes) OMEMO would be
> "moving away from OLM". As far as I'm concerned, OMEMO wasn't ever
> actually on OLM. Due to the poor standardization of signal-protocol at
> the time, we changed the spec to using OLM, but this was never
> actually implemented. There were plans to switch over, but before
> anyone got around to putting in the (not insignificant amount of)
> work, the standardization issues with signal-protocol resolved
> themselves (in particular, the whole "any implementation would be a
> derivative of ours and hence bound by the GPL" thing isn't true
> anymore, as there is a complete spec that's placed in the public
> domain). So as far as we were aware at the time, the singular
> roadblock that prevented us from standardizing on signal-protocol back
> in the day was gone, and there was no longer a strong argument for
> proceeding with this changeover, which would've meant a lot of effort
> for existing implementations at basically no concrete benefit.
>
> Hence, the main impetus driving me to work up a new revision was to
> *move the spec back in line with the real world*, not some kind of
> "political" move or anything of the sort as has been insinuated on
> this list. We've had an increasing number of developers interested in
> implementing OMEMO for different clients, and it's really dumb to have
> to tell everybody to ignore what the standard (that you yourself
> wrote) says.
>
> So what I care about is resolving this situation in a way that
> actually helps people. I want people to be able to implement this
> protocol without reading others' code or asking around which parts of
> a spec to ignore and which ones to follow. Staying in this limbo, as
> was suggested on this list at some point ("it's experimental, you can
> just stay on your private namespace for now") is in my opinion
> antithetical to the whole idea of even having a standard in the first
> place.
>
> As far as I can tell, switching to OLM does not help anyone. I am not
> aware of any individual, organization, or company that is interested
> in implementing OMEMO but *can't* due to licensing issues. The
> original criticism of lacking specification is resolved. The spec is
> public domain, and it contains everything you need to roll your own
> library. But apparently, the goalposts have moved, and we now also
> require a permissively licensed implementation.
>
> Yes, it's true that there's currently no such thing for XEdDSA, but is
> this actually a concrete problem for anyone? As far as I'm aware, this
> has always been a purely hypothetical debate. If I'm wrong here,
> please speak up! In any case, when it comes down to it, implementing
> this yourself really isn't that complex. You can re-use existing EdDSA
> code, all you need to do is write the key conversion code yourself,
> for which there is pseudo-code in the standard, which maps fairly
> directly to well-known mathematical primitives, for which you can also
> re-use existing code. The main novel idea in XEdDSA is resolving an
> ambiguity in the conversion by forcing a sign bit to 0, and that's
> about it. Your code doesn't have to be constant-time and if you do it
> wrong, the signature just won't verify. I agree that it's never ideal
> to have to do stuff like this yourself, but this also isn't quite as
> "playing with fire" as some folks are making it out to be. In any
> case, I really doubt that this is the one big thing that would hinder
> such hypothetical implementors from adopting OMEMO.
>
> To make a long story short, I remain unconvinced that switching to OLM
> makes sense at this point. The way I see it, moving forward with that
> amounts to preventing some inconvenience for an entirely hypothetical
> set of implementors at the cost of screwing over an entire existing,
> working ecosystem.
>
> It's easy to throw around things like "it's experimental, so we can
> mess with it however we like and client devs will just have to deal
> with it", especially if you have no skin in the game. But for the
> stakeholders who are actually working on and using the technology,
> stuff like this is a huge deal. OMEMO is a pretty successful and
> established protocol at this point, and to be honest I just don't see
> the major implementations switching over any time soon. Who's going to
> put in all that work? And what do we do until then?
>
> All that said, maybe my assessment of the situation is totally off. If
> the wider community still wants to move forward with this, then I
> don't want to be the only one standing in the way. But in that case,
> somebody else should probably take over.
>
> Cheers,
> Andy
>
>
>
> On 05/17/2017 05:59 PM, Dave Cridland wrote:
>> Folks,
>>
>> My understanding of OMEMO was that we (the XSF) took on the work
>> explicitly under the assumption that it was not to be based on the
>> Signal protocol, which had IPR issues, but on Olm, which was
>> explicitly designed, documented, *and* implemented to avoid such
>> issues.
>>
>> You may recall (I certainly do) lengthy discussions about OWS's
>> tendency to threaten legal action on alternate implementations of
>> their protocol, particularly their stance that *any* implementation
>> was bound by the GPL.
>>
>> As I understand things right now, in order to implement OMEMO one has
>> to fork libsignal - no other path exists without playing with
>> fundamental primitives.
>>
>> A lengthy discussion ensued on this list, involving both Matthew
>> Hodgson and others who clearly know a lot more about Crypto than I do.
>> None of their arguments were answered. Remko supplied a PR to match
>> these. It seems to be being ignored, then rejected out of hand.
>>
>> Am I wrong, if so, where?
>>
>> Dave.
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> _______________________________________________
>>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> _______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
