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: [email protected]
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
