Re: [Standards] OMEMO Discussion Summary 2017

2017-06-28 Thread Vanitas Vitae 
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

2017-06-24 Thread Remko Tronçon 
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

2017-06-22 Thread Vanitas Vitae 
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

2017-06-22 Thread Daniel Gultsch 
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

Re: [Standards] OMEMO Discussion Summary 2017

2017-06-22 Thread Florian Schmaus 
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

2017-06-22 Thread Dave Cridland 
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

Re: [Standards] OMEMO Discussion Summary 2017

2017-06-22 Thread Dave Cridland 
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

2017-06-22 Thread Chris Ballinger 
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
> ___
>

Re: [Standards] OMEMO Discussion Summary 2017

2017-06-21 Thread Peter Saint-Andre 
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

2017-06-21 Thread Dave Cridland 
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 Thread Daniel Gultsch 
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

2017-06-21 Thread Sam Whited 
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

2017-06-21 Thread Kevin Smith 
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

2017-06-21 Thread Sam Whited 
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 Thread Remko Tronçon 
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 Thread Daniel Gultsch 
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

2017-06-21 Thread Ignat Gavrilov 
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

2017-06-21 Thread Kevin Smith 
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

2017-06-21 Thread Peter Saint-Andre 
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

2017-06-21 Thread 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
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