Re: [Standards] OMEMO Discussion Summary 2017
Hi! In my recent GSoC blog post I included a small overview of the OMEMO discussion and available options for future development. I thought this might help someone who did not follow the discussion the past weeks. Note: The post contains my personal opinion :) https://blogs.fsfe.org/vanitasvitae/2017/06/28/fourth-week-of-gsoc-and-omemo-thoughts/ signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On 22 June 2017 at 09:48, Daniel Gultsch wrote: > Questions for OMEMO-NEXT for the new author to collect feedback on. > (Each of them deserves it's own thread) > Another category of questions that I think need to be added to that list is around key exchange and trust, bearing usability in mind: - How are keys validated (i.e. what's the fingerprint? Is there a fingerprint per contact, or per conversation (like what Signal does)? What in the case of multiple devices?). - Recommendation of trust models (e.g. TOFU) - Are there extensions needed to make adding new devices more usable (e.g. cross-signing of own keys to not break the TOFU model when a new device is added for the same JID). Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
Hi Dave :) Am 22.06.2017 um 00:03 schrieb Dave Cridland: > 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. In my opinion it is dangerous to try to make MIKEY-SAKKE and OMEMO compatible to one another/unite them. If I remember correctly, MIKEY-SAKKE has "master-key" capabilities (which might of course be a valid use case for enterprises) allowing a third (administrative) party to get access to messages. We should not try to work such functionality into OMEMO, because once OMEMO has such a feature, it'll be only a matter of time untill the next "anti-terror" law demands that feature to be activated for everyone by default. So as annoying as it is to have two competing standards, I think it is the way to go. Vanitasvitae ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
OK. Let's move on then. It seems like people are mostly fine with The Compromise™. Council will vote on publishing my PR as OMEMO version 0.3 next week. And I currently have no reason to expect that it will get vetoed. Afterwards we need to decide on a new author for the XEP to drive the change towards OMEMO-NEXT. That's a pretty big responsibility if we don't want OMEMO to go down the same road as its predecessors. Questions for OMEMO-NEXT for the new author to collect feedback on. (Each of them deserves it's own thread) - Do we want to break up the wire format into XML. (Both Olm and Signalprotocol are using some binary encoding format that either is protobuf or tries to be) - Do we want to continue using XedDSA or do we want to use two separate keys for signing and encrypting (Those are the two sane alternatives I guess) - Do we want to move all devices into separate items of one node. Do we keep the index-node/meta node to reduce traffic. Is there a better way in Pubsub? - Do we want to have stanza-content encryption and if so how do we do it? -- Shower thought I just had on stanza-content encryption; What if we allow stanza-content encryption only for messages and then define a second XEP that does OMEMO-based e2e-streams (maybe reusing semantics from previous XEPs) to do IQ communication. That way normal messages will still land in MAM and can be handled by carbons and so forth but we don't have the overhead of having to encrypt each and every stanza individually if we want to do a lengthier IQ-based exchange. The e2e-stream/IQ-transport thingy could thus be optional for clients that like to do IQ-based things. But I figure normal IM-clients will rarely do IQ stuff anyway these days (with each other) Please if you want to respond to any of these questions do so in separate threads or else things will get really cluttered here. And you might want to wait for the new author to get picked otherwise no one will feel responsible to collect your feedback. cheers Daniel 2017-06-21 16:35 GMT+02:00 Tobias Markmann : > 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 p
Re: [Standards] OMEMO Discussion Summary 2017
On 22.06.2017 08:45, Chris Ballinger wrote: > 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. Right. I can't think of a reason why someone would put OMEMO in a the corner of exotic, unstudied, and unaudited cyrpto primitives using protocols. > 2. OMEMO-NEXT would be great for supporting out of experiences. Assuming that with OMEMO-NEXT you mean non-XEdDSA double ratched e2e mechanism for XMPP, then I'd like to point out that support for encryption of arbitrary extension elements (non elements) could also be incorporated in Andy's PR since it's a namespace bump anyway. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On 22 Jun 2017 07:48, "Chris Ballinger" wrote: 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. I do get that. I'm not so sure it has a safe future in XMPP though. 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. Yes. It would also allow the kind of commercial deployments that have helped Signal so much. 2. OMEMO-NEXT would be great for supporting out of experiences. This too. See XEP-0200, if I recall right. That was ESessions' approach, and it seems reasonable to me as a start point. 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 cryptog
Re: [Standards] OMEMO Discussion Summary 2017
On 21 Jun 2017 23:53, "Peter Saint-Andre" wrote: 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 ;-) In my defence, it is hard to keep track of them all... ___ 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 ___
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 ___
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] 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] 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 ___