Re: [Standards] OMEMO Discussion Summary 2017
Unlike most of those things you've mentioned, SignalProtocol (the protocol and reference libraries) has been extensively studied, audited, and widely deployed to billions of mobile devices. Other than Signal itself (a few million users), it's in WhatsApp (1.2 billion users), Facebook Messenger (1.2 billion users), Allo (a few hundred users), and more. I'd guess that SignalProtocol probably has a pretty safe future with the backing of a few multibillion dollar corporations. That said: 1. I'd love a permissively licensed clean room implementation because it would help adoption and, more selfishly, allow me to offer commercial licenses of our software. 2. OMEMO-NEXT would be great for supporting out of experiences. On Wed, Jun 21, 2017 at 3:03 PM, Dave Cridland wrote: > On 21 June 2017 at 15:35, Tobias Markmann > wrote: > > Here my long overdue summary of recent OMEMO discussions. Feel free to > point > > out errors and what not. > > The only thing I'd add is a little history. I might wax a little > cynical in this. > > When I started working with XMPP (I wrote a quick and dirty XMPP > client in 24 hours), end-to-end encryption already had at least three > designs, and I think a fourth was well on the way. > > One was based on libotr, Ian Goldberg et al's original Off The Record > Messaging. It was actually only specified very recently in XMPP, > though implemented as early as 2004 I think. I think this reached > roughly the same levels of implementation as OMEMO - that is, > exclusively a single library, but wrapped into a number of popular > client projects. > > This was the "newer" kid on the block, though, the original being > CMS-based (RFC 3923). Think S/MIME for XMPP, and you're about right. > And where there's S/MIME, there's sure to be PGP - and sure enough, > XEP-0027 was around, and, as I recall, used by about five people who > bought lots of tinned food in bulk (I'm kidding - maybe - Psi had an > implementation and possibly other clients too, but I didn't see it > used much). RFC 3923 was, as befits anything based on S/MIME, used by > absolutely nobody at all. Both failed because they didn't really work > well, and were ugly as sin, too. > > The new one on the horizon was ESessions. ESessions was driven by a > single developer, and used some fairly exotic crypto to perform > roughly the same as OTR or OMEMO, albeit using older cryptographic > primitives. It had one implementation (Gajim). It was last updated a > decade ago. ESessions largely failed because it used exotic crypto > primitives. These never got an audit, as far as I'm aware, but the > fact they even needed one is a problem. Note that from a technical > standpoint, there's really nothing at all wrong with the crypto in > ESessions as far as I know. Nobody suggested there was, either. > > Then a few years on, and Silent Circle did SCIMP, which I'll count > here because although not standardized it was running on XMPP. > > Every single one of these is now long dead, though OTR limps on in a > few clients. (Unless you count OMEMO as being an ultimate derivative > of OTR and SCIMP via Signal, of course). > > There's now three that I know of (or suspect strongly exist): > > OMEMO - single library, wrapped in a handful of clients. Some of those > clients are very well deployed (although this was also true of > XEP-0027 with Psi, OTR with Gaim/Pidgin, and ESessions with Gajim). > OX - Like XEP-0027 with the deployed base of RFC 3923. > MIKEY-SAKKE - Now I *think* there are XMPP-based implementations of > this around the "Secure Chorus" market, but I've not actually seen > anything yet. It's a offline key escrow IBE system, designed for > governments and enterprises (ie, not consumers). The UK actually > mandates its use in some cases (mostly to talk to it). Take a moment > to enjoy the hysterical web search results. > > So it seems that the XMPP community is great at end-to-end encryption > - in as much as we produce an astounding number of proposals - but > less good at making them actually work in the market. > > With OX dead in the water, that leaves MIKEY-SAKKE, for the enterprise > and (UK) government, and OMEMO, for the consumer. > > It's mildly annoying to have two entirely incompatible crypto > protocols, but in fairness they're two almost entirely incompatible > markets. > > I would like not to have to update this history of failed protocols in > another few years, therefore I would like OMEMO to not fall into any > of the failure cases of previous attempts. I'd like to see lots of > fully independent interoperable implementations. I'd like to see use > of well-established, widely used cryptographic primitives. > > Dave. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: ht
Re: [Standards] OMEMO Discussion Summary 2017
On 6/21/17 4:03 PM, Dave Cridland wrote: > On 21 June 2017 at 15:35, Tobias Markmann wrote: >> Here my long overdue summary of recent OMEMO discussions. Feel free to point >> out errors and what not. > > The only thing I'd add is a little history. I might wax a little > cynical in this. You left a few out: http://stpeter.im/journal/1241.html ;-) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On 21 June 2017 at 15:35, Tobias Markmann wrote: > Here my long overdue summary of recent OMEMO discussions. Feel free to point > out errors and what not. The only thing I'd add is a little history. I might wax a little cynical in this. When I started working with XMPP (I wrote a quick and dirty XMPP client in 24 hours), end-to-end encryption already had at least three designs, and I think a fourth was well on the way. One was based on libotr, Ian Goldberg et al's original Off The Record Messaging. It was actually only specified very recently in XMPP, though implemented as early as 2004 I think. I think this reached roughly the same levels of implementation as OMEMO - that is, exclusively a single library, but wrapped into a number of popular client projects. This was the "newer" kid on the block, though, the original being CMS-based (RFC 3923). Think S/MIME for XMPP, and you're about right. And where there's S/MIME, there's sure to be PGP - and sure enough, XEP-0027 was around, and, as I recall, used by about five people who bought lots of tinned food in bulk (I'm kidding - maybe - Psi had an implementation and possibly other clients too, but I didn't see it used much). RFC 3923 was, as befits anything based on S/MIME, used by absolutely nobody at all. Both failed because they didn't really work well, and were ugly as sin, too. The new one on the horizon was ESessions. ESessions was driven by a single developer, and used some fairly exotic crypto to perform roughly the same as OTR or OMEMO, albeit using older cryptographic primitives. It had one implementation (Gajim). It was last updated a decade ago. ESessions largely failed because it used exotic crypto primitives. These never got an audit, as far as I'm aware, but the fact they even needed one is a problem. Note that from a technical standpoint, there's really nothing at all wrong with the crypto in ESessions as far as I know. Nobody suggested there was, either. Then a few years on, and Silent Circle did SCIMP, which I'll count here because although not standardized it was running on XMPP. Every single one of these is now long dead, though OTR limps on in a few clients. (Unless you count OMEMO as being an ultimate derivative of OTR and SCIMP via Signal, of course). There's now three that I know of (or suspect strongly exist): OMEMO - single library, wrapped in a handful of clients. Some of those clients are very well deployed (although this was also true of XEP-0027 with Psi, OTR with Gaim/Pidgin, and ESessions with Gajim). OX - Like XEP-0027 with the deployed base of RFC 3923. MIKEY-SAKKE - Now I *think* there are XMPP-based implementations of this around the "Secure Chorus" market, but I've not actually seen anything yet. It's a offline key escrow IBE system, designed for governments and enterprises (ie, not consumers). The UK actually mandates its use in some cases (mostly to talk to it). Take a moment to enjoy the hysterical web search results. So it seems that the XMPP community is great at end-to-end encryption - in as much as we produce an astounding number of proposals - but less good at making them actually work in the market. With OX dead in the water, that leaves MIKEY-SAKKE, for the enterprise and (UK) government, and OMEMO, for the consumer. It's mildly annoying to have two entirely incompatible crypto protocols, but in fairness they're two almost entirely incompatible markets. I would like not to have to update this history of failed protocols in another few years, therefore I would like OMEMO to not fall into any of the failure cases of previous attempts. I'd like to see lots of fully independent interoperable implementations. I'd like to see use of well-established, widely used cryptographic primitives. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0277] Should we use the whole RFC when a XEP is based upon one
Hi, a practical question: XEP-0277 is based upon Atom (RFC 4287) but doesn't use the whole spec in the specified use cases. Movim use a or to attach images: XEP-0277 doesn't talk at all about that, but it is specified in RFC 4287. Do we consider that the whole RFC is usable for XEP-0277, or only use cases specified in XEP-0277? I'm asking because those links are not handled yet in SàT, and impleting the whole RFC to handle every possible use case is far more complicated than just XEP-0277, and XMPP overlap many use cases. Implementing the whole thing makes compatibility uncertain, in the present case an image was not shown in SàT because it's the first time I see a picture attached in a rel="enclosure" link, and XEP-0277 doesn't talk about it at all. But on the other hand, it allows many more thing than the XEP alone. your opinion is really welcome on this question thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
2017-06-21 19:02 GMT+02:00 Remko Tronçon : >> I somehow got the feeling that some people on this mailing list actually >> don't want the OMEMO standard to evolve, when it does not include the >> changes they want. > > > I agree, I get the same feeling. In case you two are not the only ones with that feeling and in case 'some people' refers (among others) to me: Let me clear up the reason for my backlash. When we evolve OMEMO in a way that diverges significantly from it's current form I can no longer effort to be a driving factor behind it. (Implementing it, pushing other people to implement it, advertising it and so forth) simply because the gains from my point of view (and for my users) are not significant enough or at least are outweighed by other priorities. My worries are that without someone actually pushing the XEP and selling it to developers or finding the money to audit it, the XEP will either come to a standstill or at least wont maintain it's momentum. (Look at the OX-XEP for example that doesn't have a very active community pushing it.) My argument has never been that moving all OMEMO devices into one multiple items of the same PEP node would be a bad thing. I never said that having a liberally licensed implementations of the underlying algorithms is a bad thing. I never questioned that stanza encryption might be nice to have. I'm merely saying that all those things are hard to achieve. That's why that compromise with the warning on top of future XEP-versions linking to that usable, implemented and audited version v0.3 works well for me. Because it releases the pressure of having to come up with a version of OMEMO-NEXT within a reasonable time frame. - Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On Wed, Jun 21, 2017 at 11:30 AM, Ignat Gavrilov wrote: > We might release some of our non-libsignal-based development later this year > as open-source, but I bet it will be GPL licensed and not under one of those > "make money with third-party software and run away with it"-licenses that are > so much liked by some of the people (representing their companies interest) > here. For what it's worth, I was arguing mostly for doing Andy's proposal (which uses libsignal which is GPLed), however, I see the fact that there are only GPL implementations of X3DHE as the main problem with that proposal, I will not use GPLed software, however I do not currently work for a company who's "interests" I could represent, nor does the job I have lined up have anything to do with XMPP, or instant messaging, so I don't think people wanting a liberally licensed implementation are necessarily arguing "company interests" and we should probably avoid going down that path. A liberally licensed implementation may benefit companies as well as individuals. It is simply making things easier to adopt. Some existing non-GPL projects may not be able to use GPLed libraries, but all GPLed software can use MIT licensed (or similar) libraries. It's about making sure the most people (whether you agree with their restrictions or not) can use the library. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On 21 Jun 2017, at 18:03, Daniel Gultsch wrote: > > 2017-06-21 18:58 GMT+02:00 Daniel Gultsch : >> I think the meaning of that compromise is overstated. >> The main reason for doing this is that we have a stable version which >> can be addressed and linked to (old versions are archived) while >> development of the XEP continues. The consensus has been that people >> want to make OMEMO into something that goes far beyond what it is now. >> That's fine. But this will take time. And it will also invalidate the >> audit. That why I want - during the ongoing development of the XEP - a >> note on top of the XEP that says. 'Hey you might have heard that OMEMO >> got audited and widely implemented. But that's only true for version >> 0.3 (insert link here). We are actively working on making this XEP >> even more awesome (see below) but if you are looking for the audited >> and widely implemented version look at version 0.3' > > Forgot to mention this: The alternative would be not to link the > warning to a version in the attic but to link to a XEP hosted on my > personal webspace. I'm already hosting a version here: > https://conversations.im/omemo/xep-omemo.html > > I'm open to comments on whether people think hosting it in the attic > or on my own web space is the better idea here. I think linking to a previous version saying “This version was widely deployed” seems pretty sensible to me. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On Wed, Jun 21, 2017 at 12:03 PM, Daniel Gultsch wrote: > I'm open to comments on whether people think hosting it in the attic > or on my own web space is the better idea here. I certainly think it would be better to have it somewhere "official" (in the XSF's webspace). I do not see anyone as trying to stop the XEP from advancing; this was a compromise proposal for as reason: there are two different advancements to the XEP that people want to see, in the meantime it would be helpful if people weren't confused about what is currently implemented. It's hard to move on when you're not sure what the current state of the world is, so let's bring it back in sync with reality then decide which way it should go in the future. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
2017-06-21 18:58 GMT+02:00 Daniel Gultsch : > I think the meaning of that compromise is overstated. > The main reason for doing this is that we have a stable version which > can be addressed and linked to (old versions are archived) while > development of the XEP continues. The consensus has been that people > want to make OMEMO into something that goes far beyond what it is now. > That's fine. But this will take time. And it will also invalidate the > audit. That why I want - during the ongoing development of the XEP - a > note on top of the XEP that says. 'Hey you might have heard that OMEMO > got audited and widely implemented. But that's only true for version > 0.3 (insert link here). We are actively working on making this XEP > even more awesome (see below) but if you are looking for the audited > and widely implemented version look at version 0.3' Forgot to mention this: The alternative would be not to link the warning to a version in the attic but to link to a XEP hosted on my personal webspace. I'm already hosting a version here: https://conversations.im/omemo/xep-omemo.html I'm open to comments on whether people think hosting it in the attic or on my own web space is the better idea here. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
Hi Ignat, I somehow got the feeling that some people on this mailing list actually > don't want the OMEMO standard to evolve, when it does not include the > changes they want. > I agree, I get the same feeling. > As it seems to be the "compromise" to not evolve OMEMO in the near future > and we have a roadmap to finish e2e-encryption by end of the year, there > was no choice left then to go this step. > I don't think the compromise is to not evolve things. On the contrary, it is to unblock things so it can actually move much faster again (instead of changes from the outside being ignored for months on end because of misperceptions of the XEP). > We might release some of our non-libsignal-based development later this > year as open-source, but I bet it will be GPL licensed and not under one of > those "make money with third-party software and run away with it"-licenses > that are so much liked by some of the people (representing their companies > interest) here. > You're of course more than welcome to do so. If I were to have a commercial interest in XMPP and/or OMEMO, I probably would use GPL as well. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
2017-06-21 18:30 GMT+02:00 Ignat Gavrilov : > I somehow got the feeling that some people on this mailing list actually > don't want the OMEMO standard to evolve, when it does not include the changes > they want. > > Even though the Andy's ODR proposal is not generally in conflict with the > decision to move away from XEdDSA and/or to a solution based on two keys, the > "compromise" suggests to move back to an older (the currently implemented) > step in the XEP evolution. > The only reason I can imagine for this to be proposed by someone, is that > they fear that their changes will be off-the-table, once ODR is in place. I > don't think they are generally off-the-table, but I guess it will be a lot > harder to argue for them, because ODR strips any direct relation to the > libsignal library that is not liked (due to license or whatever) by those > persons. > I also see a lot of arguing based around the existence of (liberally > licensed) libraries. Please consider, that once we (the client devs) have a > proper standard, we can and will implement it even without using libsignal. > The existence or non-existence of a (liberally licensed) implementation of a > properly specified encryption scheme shouldn't be a major reason for > decisions. It is valid to talk about, but the time (and money) invested > talking about it already exceeded the time required to implement it. > > I already started with the note that this will be my final comment on this > issue. I don't care about the actual outcome anymore, because we (company) > did the decision to just stop waiting for standardization to continue and > implement something non-XEP-y (mostly around the ODR proposal). We are > running a non-federated, custom-client system anyway, but we would have liked > to implement a standard and not a custom protocol. As it seems to be the > "compromise" to not evolve OMEMO in the near future and we have a roadmap to > finish e2e-encryption by end of the year, there was no choice left then to go > this step. > We might release some of our non-libsignal-based development later this year > as open-source, but I bet it will be GPL licensed and not under one of those > "make money with third-party software and run away with it"-licenses that are > so much liked by some of the people (representing their companies interest) > here. Hi Ignat, thank you for taking the time to comment here even though your company decided to move on (I can't blame you.) I think the meaning of that compromise is overstated. The main reason for doing this is that we have a stable version which can be addressed and linked to (old versions are archived) while development of the XEP continues. The consensus has been that people want to make OMEMO into something that goes far beyond what it is now. That's fine. But this will take time. And it will also invalidate the audit. That why I want - during the ongoing development of the XEP - a note on top of the XEP that says. 'Hey you might have heard that OMEMO got audited and widely implemented. But that's only true for version 0.3 (insert link here). We are actively working on making this XEP even more awesome (see below) but if you are looking for the audited and widely implemented version look at version 0.3' That's all there is to the mysterious compromise. The compromise is not 'merge my current state of implementation PR and do nothing' but 'merge my PR and then go on the long journey and develop OMEMO further (and put a warning in there about experimental crypto and such) cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] length of time in ProtoXEP state
On Wed, Jun 21, 2017 at 10:47 AM, Daniel Gultsch wrote: > XEP-0001. We have countless - very essential - stuck in > very low ranks like experimental and draft. This leads to developers > implementing (and deploying to large user bases) experimental and > draft XEPs (which they are not really supposed to) which in turn leads > the XSF enforce higher standards for experimental XEPs. > > The deduplication Sam mentions for example is only supposed to happen > when something moves to draft. That's a good point; you're right, things lingering in experimental is the only reason duplicates in experimental are bad. This is the more fundamental issue to some of the things I mentioned. Although I'd also note that draft XEPs are okay to implement widely and are not "low rank". This is a separate problem though; the fact that its named "draft" makes everyone think that, including some council members and people involved in the process (I still have the "I shouldn't implement that in prod, it's just a draft" as a gut reaction after all this time). —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] length of time in ProtoXEP state
* Kevin Smith [2017-06-21 16:59]: > It's a complicated issue, and it's not clear to me that we're being > particularly stupid, It might not be clear what exactly needs to be changed to improve the standardization process. But I think it's very obvious that the result of the current process is poor. > although clearly there's room for refinement in anything. Assume a client author new to XMPP looks at https://xmpp.org/extensions/ to find out how to implement a few basic IM features; such as avatars, file sharing, blocking of spammers, and MUC bookmarks. I don't think applying a some minor "refinements" will suffice to address the problems this author will run into. Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
Hi, I'd like to add a comment here (my final one). I somehow got the feeling that some people on this mailing list actually don't want the OMEMO standard to evolve, when it does not include the changes they want. Even though the Andy's ODR proposal is not generally in conflict with the decision to move away from XEdDSA and/or to a solution based on two keys, the "compromise" suggests to move back to an older (the currently implemented) step in the XEP evolution. The only reason I can imagine for this to be proposed by someone, is that they fear that their changes will be off-the-table, once ODR is in place. I don't think they are generally off-the-table, but I guess it will be a lot harder to argue for them, because ODR strips any direct relation to the libsignal library that is not liked (due to license or whatever) by those persons. I also see a lot of arguing based around the existence of (liberally licensed) libraries. Please consider, that once we (the client devs) have a proper standard, we can and will implement it even without using libsignal. The existence or non-existence of a (liberally licensed) implementation of a properly specified encryption scheme shouldn't be a major reason for decisions. It is valid to talk about, but the time (and money) invested talking about it already exceeded the time required to implement it. I already started with the note that this will be my final comment on this issue. I don't care about the actual outcome anymore, because we (company) did the decision to just stop waiting for standardization to continue and implement something non-XEP-y (mostly around the ODR proposal). We are running a non-federated, custom-client system anyway, but we would have liked to implement a standard and not a custom protocol. As it seems to be the "compromise" to not evolve OMEMO in the near future and we have a roadmap to finish e2e-encryption by end of the year, there was no choice left then to go this step. We might release some of our non-libsignal-based development later this year as open-source, but I bet it will be GPL licensed and not under one of those "make money with third-party software and run away with it"-licenses that are so much liked by some of the people (representing their companies interest) here. Ignat. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] length of time in ProtoXEP state
On 21 Jun 2017, at 16:47, Daniel Gultsch wrote: > > The problem here is that XEPs usually don't move up the ranks as it is > intended by XEP-0001. We have countless - very essential - stuck in > very low ranks like experimental and draft. This leads to developers > implementing (and deploying to large user bases) experimental and > draft XEPs (which they are not really supposed to) which in turn leads > the XSF enforce higher standards for experimental XEPs. > > The deduplication Sam mentions for example is only supposed to happen > when something moves to draft. > > So I think we got into that situation somewhat by accident and/or by > our disability to advance XEPs at a reasonable pace. I think it’s partly because Experimental and Draft and Final look the same to all but a particularly interested observer. This makes it heavily disadvantageous to publish duplicate XEPs, for example. Also, given the IPR considerations, it would be poor form to accept XEPs (and take the IP) that anyone with an involvement could see would be blocked from progressing. It’s a complicated issue, and it’s not clear to me that we’re being particularly stupid, although clearly there’s room for refinement in anything. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] length of time in ProtoXEP state
The problem here is that XEPs usually don't move up the ranks as it is intended by XEP-0001. We have countless - very essential - stuck in very low ranks like experimental and draft. This leads to developers implementing (and deploying to large user bases) experimental and draft XEPs (which they are not really supposed to) which in turn leads the XSF enforce higher standards for experimental XEPs. The deduplication Sam mentions for example is only supposed to happen when something moves to draft. So I think we got into that situation somewhat by accident and/or by our disability to advance XEPs at a reasonable pace. The fact that standards development is being spread out over years also leads to the interesting effect that the original author might no longer be interested/involved which will further delay the development because nobody feels responsible for that particular XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] length of time in ProtoXEP state
On Wed, Jun 21, 2017 at 9:53 AM, Peter Saint-Andre wrote: > The OMEMO saga (of which I am only a distant observer) raises a more > general issue: leaving a specification in the ProtoXEP state for way too > long. OMEMO is actually in experimental; so I'm not sure this applies to the OMEMO discussion (which is more about continued development when a group at the XSF disagrees with the direction the author wants to take the spec). > I have always been an advocate of accepting a proposal for XEP > publication as quickly as possible, in part to avoid this kind of limbo. > Indeed, in the early days acceptance for publication was handled by the > XEP Editor and the Council wasn't involved at all. Although I was never > sure what problems Council involvement was designed to avoid, it sure > seems to have caused new problems. By "for publication" do you mean moving from ProtoXEP to Experimental? If so, with my council hat on I agree that having the council review protoxeps for publication is not strictly necessary. With my editor hat on: I don't want the responsibility of rejecting XEPs that don't meet a certain standard, that just sounds like a great way for people to acuse me of bias or playing favorites (which is at least spread over a group of people if it's voted on in committee). I'd also be worried that I'd have to accept a lot of duplicates, poor protocols, etc. and the experimental XEPs would become even more confusing for developers wondering what to implement. So I could take it or leave it. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] length of time in ProtoXEP state
The OMEMO saga (of which I am only a distant observer) raises a more general issue: leaving a specification in the ProtoXEP state for way too long. I have always been an advocate of accepting a proposal for XEP publication as quickly as possible, in part to avoid this kind of limbo. Indeed, in the early days acceptance for publication was handled by the XEP Editor and the Council wasn't involved at all. Although I was never sure what problems Council involvement was designed to avoid, it sure seems to have caused new problems. Peter -- Peter Saint-Andre http://stpeter.im/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On 21 Jun 2017, at 15:47, Peter Saint-Andre wrote: > > Thanks for the summary, Tobias! > > On 6/21/17 8:35 AM, Tobias Markmann wrote: > > >> With that, the media and client developers can point to the version of >> XEP-0384 that is currently widely implemented and the XSF community is >> free to improve the end-to-end security standard OMEMO in XEP-0384 >> without the constraints of existing implementations which might follow >> way proposal e) or proposal f) or something else entirely. > > The XSF has not traditionally done a wonderful job of archiving previous > versions. I'm concerned that we'd lose track of the SIACS version. Why > wouldn't we continue development of the Olm versions under a new XEP > number, as for instance we've done with XEP-0176 and XEP-0371 or > XEP-0115 and XEP-0390? See the very long threads that took us to get to this compromise. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
Thanks for the summary, Tobias! On 6/21/17 8:35 AM, Tobias Markmann wrote: > With that, the media and client developers can point to the version of > XEP-0384 that is currently widely implemented and the XSF community is > free to improve the end-to-end security standard OMEMO in XEP-0384 > without the constraints of existing implementations which might follow > way proposal e) or proposal f) or something else entirely. The XSF has not traditionally done a wonderful job of archiving previous versions. I'm concerned that we'd lose track of the SIACS version. Why wouldn't we continue development of the Olm versions under a new XEP number, as for instance we've done with XEP-0176 and XEP-0371 or XEP-0115 and XEP-0390? Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OMEMO Discussion Summary 2017
Hi, Here my long overdue summary of recent OMEMO discussions. Feel free to point out errors and what not. Cheers, Tobi Overview The OMEMO protocol [0, 1] aims to bring end-to-end security to XMPP. It is currently based on the Signal [2] protocol. At its core it is based on elliptic-curve cryptography and symmetric cryptography. This email aims to summarise the recent discussions around OMEMO in the previous months, provide a short history of the XSF related development of the XEP and the discussions. It does not reference every discussion contribution and is by no means complete. However, I've tried my best. For full history, see the mailing list archives. Please let me know if I understood some parts of the discussion wrong or wrongly paraphrased people. TLDR OMEMO is an end-to-end security protocol for XMPP that originated from Google Summer of Code. It was a ProtoXEP for some time that got widely implemented. It was changed in the process of becoming a XSF XEP. Now further development of the XSF XEP is about to happen. Currently there are: a) SIACS OMEMO (implemented in the wild) using the Signal protocol b) XSF OMEMO (not implemented anywhere) which currently uses Olm instead of the Signal protocol There are different proposals to move forward form here: c) Using OMEMO Double Ratchet (ODR) and X3DH from Andreas Straub (original OMEMO author) https://github.com/xsf/xeps/pull/460 d) Continue using Olm and updating upon it from Remko Tronçon: https://github.com/xsf/xeps/pull/463 There are basically two major groups in the discussion: e) We should follow what libsignal does (X3DH) as currently all SIACS OMEMO implementation use libsignal to provide OMEMO. - This is currently only available in libsignal and the java signal library and bindings to them. Both available under GPLv3. f) We should go with Olm and more standard crypto primitives as they can be found in OpenSSL, BouncyCastle, etc. - The argument for this approach is that it uses general crypto that's been well known and tested. It's widely available in most programming environments. It is also provided by libraries with a liberal software license (MIT/BSD/Apache and that like). This provides more choice on how to implement the protocol and the crypto primitives do not have to be implemented by the chat application developers. - Furthermore, regardless on how the OMEMO development continues, a lot media points to the XSF XEP when mentioning OMEMO and that doesn't currently reflect what's implemented in the wild. Thus the suggestion of Kevin Smith was to specify what's currently implemented in the wild as a new version in XEP-0384 which people can refer to. New developments then can continue from there in XEP-0384 following the usual XSF process of discussions of proposed changes on the mailing list, consensus, etc. With that, the media and client developers can point to the version of XEP-0384 that is currently widely implemented and the XSF community is free to improve the end-to-end security standard OMEMO in XEP-0384 without the constraints of existing implementations which might follow way proposal e) or proposal f) or something else entirely. Daniel wrote a PR that brings the XSF OMEMO XEP in line with the implementations out there https://github.com/xsf/xeps/pull/470 . Timeline of OMEMO as a XSF specification and surrounding recent discussions --- 2015-10-28: 1st proposal of OMEMO as XEP https://mail.jabber.org/pipermail/standards/2015-October/030544.html 2015-11-13: Thijs Alkemade raises concerts about the proposed specification, as the underlying crypto protocol is not publicly specified and has only a single implementation, a GPLv3 licensed library https://mail.jabber.org/pipermail/standards/2015-November/030622.html 2015-12-23: Andreas Straub clarifies the specification used in OMEMO and the various TextSecure/Signal protocol versions around. https://mail.jabber.org/pipermail/standards/2015-December/030725.html 2015-12-25: Thijs Alkemade states that the publicly available TextSecure v2 protocol documentation is insufficient and doesn't specify the hash used in their HKDF. He points to the OLM specification of the Matrix project as an example of a very similar protocol with a detailed specification including the crypto primitives to be used. https://mail.jabber.org/pipermail/standards/2015-December/030727.html 2016-04-12: Dave Cridland also points to the Olm specification, which is a based on Axolotl but decently specified. https://mail.jabber.org/pipermail/standards/2016-April/031026.html 2016-10-01: Daniel Gultsch points to his PR that changes the OMEMO ProtoXEP to use the Olm specification and includes some minor improvements that came up in the OMEMO audit. https://mail.jabber.org/pipermail/standards/2016-October/031460.html 2016-10-31: The new version of the OMEMO Pro