On 24 May 2017 at 21:55, Andreas Straub <a...@strb.org> wrote: > 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. >
Yes, your recent lack of response has indeed been seen as unresponsive. > 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. And yet this was explicitly a prerequisite for accepting the XEP. So I shall assume that you had no intention of adhering to the decisions of the Council. I've said before that I find this kind of "bait and switch" both deceitful and unacceptable. I didn't think it was required to stipulate that participation within the XSF should be in good faith. At the time of the XEP's acceptance, I thought we had agreement from the (then very few) implementers that they'd switch to follow the specification. It seems this was merely a political move to get the XEP number. This is very poor behaviour. Rightly or wrongly, there are other benefits of using Olm, such as interoperability with Matrix, the availability of existing low and high level libraries, etc. While the major reason was lack of a specification and legal concerns, these were not the only reasons, and second-guessing the Council's decision is not helpful. > 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. > I would feel more sympathy in this if there were another implementation. But it looks rather strongly as if every extant implementation of OMEMO is simply a wrapper around a single crypto implementation. So while "can't" is technically untrue, "won't" seems very much to be the case. In any standards organisation, we want to build specifications that can yield independent, interoperable implementations. OMEMO has, inarguably, failed to do so due to reliance on some odd cryptographic primitives. > 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. > And yet: a) There are NO implementations which are written independently. b) There are, on the other hand, people who have said they'd like to implement, but won't. So you can doubt as much as you like, but the facts remain that there are no implementations of OMEMO which are not built on libsignal, and no implementations of OMEMO which are not GPL. Your counter-argument seems to be that the reasons for this are... because people are lazy? Stupid? Because... What? > 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. > You keep using the word "hypothetical". I do not think it means what you think it means. I've met Remko, and I can assure you he is a real person. If he is your hypothesis, then I can assure you he can be proven to exist. > 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? > Well, in fairness, had you changed the implementation back when the XEP was published to match it, we wouldn't be in this situation now. In other words, had you done what everyone involved agreed. That said, I am highly sympathetic to cases where we would like to change a spec, but the existing spec has wide deployment of independent, interoperable implementations. I made this argument with Carbons, for example. In that case, there were numerous clients and servers that all implemented the specification as written. I am entirely open to similar arguments where the specification is at odds with the deployment, as well - where all implementations deviate from the spec in some way, or even share the same bugs, it's right to change the specification. But the problem here is that one can, by your admission, only implement OMEMO - or, in your words, get "skin in the game" - by following your unpublished design, using a single underlying library, and if one has not implemented for any reason you discard their arguments. This means that your argument is effectively that the only people whose opinion matters are the people who already agree with you. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
