Re: [Standards] Council Minutes 2017-05-24

[Kevin Smith]

On 24 May 2017, at 21:03, Dave Cridland  wrote:
> 
> On 24 May 2017 at 20:30, Evgeny Khramtsov  wrote:
>> Wed, 24 May 2017 21:24:40 +0200
>> Daniel Gultsch  wrote:
>> 
>>> The author is unresponsive and has been ignoring my feedback for over
>>> a year.
>> 
>> Like always, hehe :/
> 
> Sorry, I wasn't aware that this one had got stalled.
> 
> I got hold of Lance and checked - he's obviously missed a couple more
> messages than he thought, but he's too busy right now. (He also says
> Daniel's feedback was all good).
> 
> Do you (or anyone else) want to take it on?

I could if it makes sense, I have an interest in this area now.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Push. Was Re: Council Minutes 2017-05-24

[Kevin Smith]

On 24 May 2017, at 20:34, Daniel Gultsch  wrote:
> 
> https://mail.jabber.org/pipermail/standards/2016-February/030925.html
> 
> The follow up message from Holger (Timeout only starts after first
> push-worthy stanza) is also important.
> 
> We also came to the conclusion that it is desirable to actively close
> the TCP connection if an  from the server remains unanswered after
> ~30 seconds or so. This is due to some platforms (read Android) not
> allowing us to properly close the connection ourself. (But this is
> probably a business rule for SM and not for Push). It also handled in
> that module.
> 
> Both the prosody module as well as the unpublished ejabberd follow
> those business rules.

Thanks Daniel. I don’t (only) want to be contrary, but I would like these to be 
at most suggestions in the XEP (I’m not opposed to including them for the sake 
of server devs who want guidance, but I don’t think they should be normative). 
When I was thinking about this the other day I came up with a somewhat 
different scheme, which I’d like to also be allowable (I see no reason it 
shouldn’t be, given that it doesn’t cause interop problems).

In related news, I think there’s value in extending this (optionally seems 
fine) to support retractions too. If a server knows that all the unread 
messages that it’s sent notifications for have now been read, it seems 
reasonable for it to be able to tell the XMPP Push Service to tell the device 
that.

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

Am 25.05.2017 um 16:37 schrieb Remko Tronçon:

> Don't forget the other part of your mail: if it also comes with one of
> your 
> 2 other proposals (split ed25519/curve25519 identity keys, or
> (widespread) permissibly 
> licensed implementation of XEdDSA)
>
> Remko
>

Sure :)


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 and Olm

[Remko Tronçon]

On 25 May 2017 at 15:53, Vanitas Vitae  wrote:

> So if that last part is resolved (which shouldn't be a big deal), then
> Andys PR would be an accpetable compromise for everyone, am I right?
>

Don't forget the other part of your mail: if it also comes with one of your
2 other proposals (split ed25519/curve25519 identity keys, or (widespread)
permissibly
licensed implementation of XEdDSA)

Remko
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Germán Márquez Mejía]

Hi,

Am Donnerstag, den 25.05.2017, 15:53 +0200 schrieb Vanitas Vitae:
> So if that last part is resolved (which shouldn't be a big deal),
> then
> Andys PR would be an accpetable compromise for everyone, am I right?

It is acceptable for me.

+1


Mancho

signature.asc
Description: This is a digitally signed message part
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

Am 25.05.2017 um 15:49 schrieb Remko Tronçon:
>> There are concerns about the usage of XEdDSA, which could be solved by
>> either implementing the XEdDSA conversion function in a non-GPL way
> This would help, but I'll still feel very uneasy until it is available in an 
> accepted crypto library. 
>
> Other than that, I agree with your summary. 
>
>
>> Either way, are there any other points speaking against Andys PR?
> Yes: the wire format isn't specified (how is chain length etc. authenticated)

So if that last part is resolved (which shouldn't be a big deal), then
Andys PR would be an accpetable compromise for everyone, am I right?
Its nice to see some progress in that case :)

Vanitasvitae



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 and Olm

[Remko Tronçon]

> 
> There are concerns about the usage of XEdDSA, which could be solved by
> either implementing the XEdDSA conversion function in a non-GPL way

This would help, but I'll still feel very uneasy until it is available in an 
accepted crypto library. 

Other than that, I agree with your summary. 


> Either way, are there any other points speaking against Andys PR?

Yes: the wire format isn't specified (how is chain length etc. authenticated)

Remko
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

Am 25.05.2017 um 15:25 schrieb Dave Cridland:
> Perhaps. Ed25519 and EdDSA are used (or proposed to be) in many places
> (DNSSEC, TLS, etc), so it *is* natural that it's implemented much more
> widely. But of course, that also raises the question of why XEdDSA is
> not proposed in DNSSEC, TLS, and so on. I suspect it's just fashion,
> but it'd make me a lot happier to be using crypto primitives that
> everyone else was, too, nonetheless.
>
> Dave.

So to summarize the current state of the discussion:

There are concerns about the usage of XEdDSA, which could be solved by
either implementing the XEdDSA conversion function in a non-GPL way
(which could also then be used in Olm), or by using two seperate keys
instead of just one. Afaik Andys PR does not cover the later option
right now, but I guess that could be easily added.

Either way, are there any other points speaking against Andys PR? I have
the feeling, that XEdDSA is the only real blocker right now (again,
which can be solved).

Vanitasvitae



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 and Olm

[Daniel Gultsch]

2017-05-25 15:25 GMT+02:00 Dave Cridland :
> On 25 May 2017 at 14:15, Daniel Gultsch  wrote:
>> 2017-05-25 14:56 GMT+02:00 Dave Cridland :
>>> Proponents of XEdDSA (and libsignal) have repeatedly made the claim
>>> that building an XEdDSA implementation is both safe and
>>> straightforward.
>>>
>>> My concern is that nobody has done so.
>>>
>>> There might be perfectly sound reasons for this, such as everyone
>>> working on this has a particular desire for GPL'd output. I'm not sure
>>> that thrills me, but still.
>>
>> I wouldn't say particular desire for GPL but rather 'not being bothered' by 
>> GPL.
>> All current OMEMO implementations are 'traditional' open source
>> clients that are either GPL already or can live with a GPL
>> re-licensing when OMEMO is enabled.
>>
>
> Including one Apache-licensed library, though.
>
>> It's perfectly understandable that those clients are picking the path
>> of least resistance and are going with a libsignal-protocol variant.
>> This does not however speak in any form towards the (im)possibility to
>> create an ODR library based on Olm.
>>
>
> I get that this is the path of least resistance for clients that are
> already GPL. Seems really odd for it to be the path of least
> resistance when it involves relicensing.


There is another factor that current implementations that are using
siacs-OMEMO/pre-OMEMO what ever you wanna call it have to use
libsignalprotocol because of the wire format.
This is exactly what ODR is trying to overcome.
And again this is no indication whatsoever regarding the viability of
creating an ODR compatible (w/ XEdDSA) Ratchet based on the olm
library.

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Dave Cridland]

On 25 May 2017 at 14:15, Daniel Gultsch  wrote:
> 2017-05-25 14:56 GMT+02:00 Dave Cridland :
>> Proponents of XEdDSA (and libsignal) have repeatedly made the claim
>> that building an XEdDSA implementation is both safe and
>> straightforward.
>>
>> My concern is that nobody has done so.
>>
>> There might be perfectly sound reasons for this, such as everyone
>> working on this has a particular desire for GPL'd output. I'm not sure
>> that thrills me, but still.
>
> I wouldn't say particular desire for GPL but rather 'not being bothered' by 
> GPL.
> All current OMEMO implementations are 'traditional' open source
> clients that are either GPL already or can live with a GPL
> re-licensing when OMEMO is enabled.
>

Including one Apache-licensed library, though.

> It's perfectly understandable that those clients are picking the path
> of least resistance and are going with a libsignal-protocol variant.
> This does not however speak in any form towards the (im)possibility to
> create an ODR library based on Olm.
>

I get that this is the path of least resistance for clients that are
already GPL. Seems really odd for it to be the path of least
resistance when it involves relicensing.

> On top of that the ODR version of the XEP hasn't even been published
> yet, thus the fact that there is no XEdDSA library only speaks for the
> lack of interest.

Perhaps. Ed25519 and EdDSA are used (or proposed to be) in many places
(DNSSEC, TLS, etc), so it *is* natural that it's implemented much more
widely. But of course, that also raises the question of why XEdDSA is
not proposed in DNSSEC, TLS, and so on. I suspect it's just fashion,
but it'd make me a lot happier to be using crypto primitives that
everyone else was, too, nonetheless.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Daniel Gultsch]

2017-05-25 14:56 GMT+02:00 Dave Cridland :
> Proponents of XEdDSA (and libsignal) have repeatedly made the claim
> that building an XEdDSA implementation is both safe and
> straightforward.
>
> My concern is that nobody has done so.
>
> There might be perfectly sound reasons for this, such as everyone
> working on this has a particular desire for GPL'd output. I'm not sure
> that thrills me, but still.

I wouldn't say particular desire for GPL but rather 'not being bothered' by GPL.
All current OMEMO implementations are 'traditional' open source
clients that are either GPL already or can live with a GPL
re-licensing when OMEMO is enabled.

It's perfectly understandable that those clients are picking the path
of least resistance and are going with a libsignal-protocol variant.
This does not however speak in any form towards the (im)possibility to
create an ODR library based on Olm.

On top of that the ODR version of the XEP hasn't even been published
yet, thus the fact that there is no XEdDSA library only speaks for the
lack of interest.

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Dave Cridland]

On 25 May 2017 at 13:12, Vanitas Vitae  wrote:
> Am 25.05.2017 um 13:57 schrieb Matthew Hodgson:
>
>> But if OMEMO-using-libsignal has critical mass already, I completely
>> get the concerns over disrupting the existing ecosystem over 'just' a
>> licensing issue, and perhaps the work would be better spent writing an
>> liberal-licensed ratchet which is absolutely 100% compatible with
>> libsignal (including XEdDSA) etc.  This could be by extending/forking
>> Olm to use XEdDSA, or if you're feeling completely masochistic, a
>> whole new implementation.  Then folks on OMEMO-using-libsignal would
>> be able to talk happily to folks on
>> OMEMO-using-liberal-licensed-DR-implementation, and everyone's happy
>> (i think?)
>
> Thats the idea of Andys ODR spec; decoupling the xep from libsignal/olm
> to allow any library to be used.
>
>> For the record, if someone did jump through the hoops to make Olm talk
>> XEdDSA we'd probably consider using it on the Matrix side (both to
>> avoid a fork, and to help pool crypto resources between XMPP & Matrix,
>> and keep compatibility with folks who want to use GPL-licensed
>> libsignal, etc).
>
> Thats great news :) Also this indicates that there is more interest in
> XEdDSA than just from within the "Signal-OMEMO"-community.
>
>> (In other news, I saw Remko mention elsewhere that an advantage of Olm
>> might be using Megolm-style semantics for XMPP.  I'd caution that
>> Megolm is very much experimental still, and we're not sure all the
>> design decisions are optimal.  More importantly, it's completely
>> decoupled from Olm, despite the name, and could be layered on top of a
>> libsignal-managed 1:1 channel just as much as an olm-managed one).
>
> Thanks for the clarification on this one.
>
>
> Am 25.05.2017 um 10:47 schrieb Dave Cridland:
>
>> But it looks rather strongly as if every extant implementation of
>> OMEMO is simply a wrapper around a single crypto implementation.
>
> Than what's the difference when the XEP is switched over to use Olm?
> What would that change aside from another single crypto implementation
> being used?
>

My understanding is that one can "knock up" and Olm implementation
from existing crypto libraries. Ed25519, for example, is in several
crypto libraries, in several languages, whereas XEdDSA is only found
in libsignal currently. Support for Ed25519 (and Curve25519) is, for
example, coming "real soon now" in OpenSSL:
https://github.com/openssl/openssl/pull/3503 - but there's no sign at
all of XEdDSA that I can find.

Proponents of XEdDSA (and libsignal) have repeatedly made the claim
that building an XEdDSA implementation is both safe and
straightforward.

My concern is that nobody has done so.

There might be perfectly sound reasons for this, such as everyone
working on this has a particular desire for GPL'd output. I'm not sure
that thrills me, but still.

Dave
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Daniel Gultsch]

2017-05-25 13:57 GMT+02:00 Matthew Hodgson :
> But if OMEMO-using-libsignal has critical mass already, I completely get the
> concerns over disrupting the existing ecosystem over 'just' a licensing
> issue, and perhaps the work would be better spent writing an
> liberal-licensed ratchet which is absolutely 100% compatible with libsignal
> (including XEdDSA) etc.  This could be by extending/forking Olm to use
> XEdDSA, or if you're feeling completely masochistic, a whole new
> implementation.  Then folks on OMEMO-using-libsignal would be able to talk
> happily to folks on OMEMO-using-liberal-licensed-DR-implementation, and
> everyone's happy (i think?)

+1

That's pretty much the idea behind ODR.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Matthew Hodgson]

On 5/25/17 12:31 PM, Vanitas Vitae wrote:

Hi!

Am 25.05.2017 um 10:47 schrieb Dave Cridland:
Rightly or wrongly, there are other benefits of using Olm, such as 
interoperability with Matrix, the availability of existing low and 
high level libraries, etc.

Correct me if I'm wrong, but there is still no java implementation,
right?


There is http://matrix.org/git/olm/tree/android, which provides JNI 
wrappers around libolm for use in Java.  In general this is preferable 
(performancewise and auditwise) to a native Java implementation.


There's also someone in the community shifting the build from being 
android/gradle to generic Java, although this isn't exactly a lot of work.


In terms of the general question of libsignal-* versus Olm: it's worth 
noting that using precisely the same ratchet for both Matrix & XMPP 
doesn't necessarily buy much, given the payloads put over the ratchet 
will end up being inevitably different.  The main advantage of doing so 
would be to just benefit from the audit & ongoing maintenance work 
that's going into Olm, as well as the more liberal licensing.


But if OMEMO-using-libsignal has critical mass already, I completely get 
the concerns over disrupting the existing ecosystem over 'just' a 
licensing issue, and perhaps the work would be better spent writing an 
liberal-licensed ratchet which is absolutely 100% compatible with 
libsignal (including XEdDSA) etc.  This could be by extending/forking 
Olm to use XEdDSA, or if you're feeling completely masochistic, a whole 
new implementation.  Then folks on OMEMO-using-libsignal would be able 
to talk happily to folks on 
OMEMO-using-liberal-licensed-DR-implementation, and everyone's happy (i 
think?)


For the record, if someone did jump through the hoops to make Olm talk 
XEdDSA we'd probably consider using it on the Matrix side (both to avoid 
a fork, and to help pool crypto resources between XMPP & Matrix, and 
keep compatibility with folks who want to use GPL-licensed libsignal, etc).


(In other news, I saw Remko mention elsewhere that an advantage of Olm 
might be using Megolm-style semantics for XMPP.  I'd caution that Megolm 
is very much experimental still, and we're not sure all the design 
decisions are optimal.  More importantly, it's completely decoupled from 
Olm, despite the name, and could be layered on top of a 
libsignal-managed 1:1 channel just as much as an olm-managed one).


M


--
Matthew Hodgson
Matrix.org
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Vanitas Vitae]

Hi!

Am 25.05.2017 um 10:47 schrieb Dave Cridland:
> Rightly or wrongly, there are other benefits of using Olm, such as
> interoperability with Matrix, the availability of existing low and
> high level libraries, etc. 
Correct me if I'm wrong, but there is still no java implementation, right?

Vanitasvitae



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

2017-05-25 13:20 GMT+02:00 Dave Cridland :
> On 25 May 2017 at 12:16, Daniel Gultsch  wrote:
>> Small clarification on my own wording:
>>
>> 2017-05-16 19:07 GMT+02:00 Daniel Gultsch :
>>> - If a certain form field is registered with the registry [1] all
>>> server implementations MUST behave according to the specification in
>>> [1].
>>
>> This should read:
>> If a certain form field is registered with the registry [1] AND the
>> pubsub services announces #publish-options as a feature all server
>> implementations MUST behave according to the specification in [1].
>>
>> The reason I want this to be cleared up either on this list or even
>> better in section 7.1.5 of XEP-0060 is that this has the potential to
>> save me a lot of round trips when regularly publishing items to pubsub
>> nodes with a specific access model.
>> Without it I would have to explicitly configure the node every time
>> before I post an item. On the other hand if my assumptions are correct
>> I can publish items on a whim, having the server reject the
>> publication if the access model doesn't match and only in that
>> (probably rare case) configure the node and republish the item.
>
> So you want the outcome to be:
>
> a) The publish option is known to the server, in which case it is
> treated as a precondition or override as given in the registry.

Yes. If a certain publish-option is registered I want the server to
treat as either a a precondition, override or metadata depending on
what is described in the registry.

> b) The publish option is not known to the server, in which case the
> publish is rejected.

In general I do not care how the server handles unregistered options.
However since the list of registered options can grow without the
server knowing about it I guess having the server reject every unknown
option is a consequence of (a).


cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Privacy Rules and MAM interaction

[Dave Cridland]

On 20 May 2017 at 17:45, Evgeny Khramtsov  wrote:
> Sat, 20 May 2017 11:12:18 -0500
> Sam Whited  wrote:
>
>> I was simply advising that making your MAM module interact with
>> privacy lists may be something you want to consider avoiding.
>
> But I simply cannot avoid it. If a user has two connected resources
> with different active lists, what should I do?

Default sounds right, though in practise if the message would be
delivered by the default or any active list, you might as well store
it.

The specification covers this to some degree in the third paragraph of
section 5.1, the guideline being that if a client "would have received
it", it goes into the archive, and if the message is rejected, it
shouldn't go into the archive.

For the XEP-0191 case, that seems straightforward enough, for the
Privacy Lists case it's more complex, but I think Default would do -
though default or any active seems more in line with the intent here.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Dave Cridland]

On 25 May 2017 at 12:16, Daniel Gultsch  wrote:
> Small clarification on my own wording:
>
> 2017-05-16 19:07 GMT+02:00 Daniel Gultsch :
>> - If a certain form field is registered with the registry [1] all
>> server implementations MUST behave according to the specification in
>> [1].
>
> This should read:
> If a certain form field is registered with the registry [1] AND the
> pubsub services announces #publish-options as a feature all server
> implementations MUST behave according to the specification in [1].
>
> The reason I want this to be cleared up either on this list or even
> better in section 7.1.5 of XEP-0060 is that this has the potential to
> save me a lot of round trips when regularly publishing items to pubsub
> nodes with a specific access model.
> Without it I would have to explicitly configure the node every time
> before I post an item. On the other hand if my assumptions are correct
> I can publish items on a whim, having the server reject the
> publication if the access model doesn't match and only in that
> (probably rare case) configure the node and republish the item.

So you want the outcome to be:

a) The publish option is known to the server, in which case it is
treated as a precondition or override as given in the registry.
b) The publish option is not known to the server, in which case the
publish is rejected.

Does that seem about right?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

Small clarification on my own wording:

2017-05-16 19:07 GMT+02:00 Daniel Gultsch :
> - If a certain form field is registered with the registry [1] all
> server implementations MUST behave according to the specification in
> [1].

This should read:
If a certain form field is registered with the registry [1] AND the
pubsub services announces #publish-options as a feature all server
implementations MUST behave according to the specification in [1].

The reason I want this to be cleared up either on this list or even
better in section 7.1.5 of XEP-0060 is that this has the potential to
save me a lot of round trips when regularly publishing items to pubsub
nodes with a specific access model.
Without it I would have to explicitly configure the node every time
before I post an item. On the other hand if my assumptions are correct
I can publish items on a whim, having the server reject the
publication if the access model doesn't match and only in that
(probably rare case) configure the node and republish the item.

- Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Remko Tronçon]

On Thu, 25 May 2017 at 11:02, Florian Schmaus  wrote:

>
> Thanks Dave, but Remko's statement reads like *every* OMEMO
> implementation based on libsignal is legally not in order


I meant to say 1, not every.

Remko

>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Dave Cridland]

On 25 May 2017 at 10:01, Florian Schmaus  wrote:
> On 25.05.2017 10:56, Dave Cridland wrote:
>> On 25 May 2017 at 08:26, Florian Schmaus  wrote:
>>> On 25.05.2017 08:04, Remko Tronçon wrote:
 On 24 May 2017 at 22:55, Andreas Straub > wrote:
> I just don't see the major implementations switching over any time soon

 I have serious doubts that at least one of them won't have to do *some*
 significant work to get rid of the libsignal dependency to be legally in
 order, which will mean implementing the ratchet and XEdDSA itself
 (unless a library emerges that implements this all from scratch).
>>>
>>> Why do you think the existing implementations using libsignal are not
>>> legally in order?
>>>
>>
>> I think Smack, while legally in order, is in trouble here.
>
> Thanks Dave, but Remko's statement reads like *every* OMEMO
> implementation based on libsignal is legally not in order. Which is a
> pretty strong claim, and is borderline, or at least gives the impression
> of spreading fear, uncertainty and doubt.
>

I did not read Remko's statement in that way.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Kevin Smith]

On 25 May 2017, at 10:01, Florian Schmaus  wrote:
> 
> On 25.05.2017 10:56, Dave Cridland wrote:
>> On 25 May 2017 at 08:26, Florian Schmaus  wrote:
>>> On 25.05.2017 08:04, Remko Tronçon wrote:
 On 24 May 2017 at 22:55, Andreas Straub > wrote:
> I just don't see the major implementations switching over any time soon
 
 I have serious doubts that at least one of them won't have to do *some*
 significant work to get rid of the libsignal dependency to be legally in
 order, which will mean implementing the ratchet and XEdDSA itself
 (unless a library emerges that implements this all from scratch).
>>> 
>>> Why do you think the existing implementations using libsignal are not
>>> legally in order?
>>> 
>> 
>> I think Smack, while legally in order, is in trouble here.
> 
> Thanks Dave, but Remko's statement reads like *every* OMEMO
> implementation based on libsignal is legally not in order.

It seems to me fairly unambiguous that “At least one” isn’t equal to “every” 
(except in the case where there is only one).

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OMEMO and Olm

[Florian Schmaus]

On 25.05.2017 10:56, Dave Cridland wrote:
> On 25 May 2017 at 08:26, Florian Schmaus  wrote:
>> On 25.05.2017 08:04, Remko Tronçon wrote:
>>> On 24 May 2017 at 22:55, Andreas Straub >> > wrote:
 I just don't see the major implementations switching over any time soon
>>>
>>> I have serious doubts that at least one of them won't have to do *some*
>>> significant work to get rid of the libsignal dependency to be legally in
>>> order, which will mean implementing the ratchet and XEdDSA itself
>>> (unless a library emerges that implements this all from scratch).
>>
>> Why do you think the existing implementations using libsignal are not
>> legally in order?
>>
> 
> I think Smack, while legally in order, is in trouble here.

Thanks Dave, but Remko's statement reads like *every* OMEMO
implementation based on libsignal is legally not in order. Which is a
pretty strong claim, and is borderline, or at least gives the impression
of spreading fear, uncertainty and doubt.

I hope we do not reach those levels in any discussion within the XSF.

- 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 and Olm

[Dave Cridland]

On 24 May 2017 at 21:55, Andreas Straub  wrote:
> Hey all,
>
> it has been brought to my attention that my recent silence on this matter is
> being perceived as "unresponsiveness", so I guess I should clear up a few
> things.
>

Yes, your recent lack of response has indeed been seen as unresponsive.

> First, for a bit of additional background, I suppose I should clear up the
> misconception that (under my proposed changes) OMEMO would be "moving away
> from OLM". As far as I'm concerned, OMEMO wasn't ever actually on OLM.

And yet this was explicitly a prerequisite for accepting the XEP. So I
shall assume that you had no intention of adhering to the decisions of
the Council. I've said before that I find this kind of "bait and
switch" both deceitful and unacceptable. I didn't think it was
required to stipulate that participation within the XSF should be in
good faith.

At the time of the XEP's acceptance, I thought we had agreement from
the (then very few) implementers that they'd switch to follow the
specification. It seems this was merely a political move to get the
XEP number. This is very poor behaviour.

Rightly or wrongly, there are other benefits of using Olm, such as
interoperability with Matrix, the availability of existing low and
high level libraries, etc. While the major reason was lack of a
specification and legal concerns, these were not the only reasons, and
second-guessing the Council's decision is not helpful.

> As far as I can tell, switching to OLM does not help anyone. I am not aware
> of any individual, organization, or company that is interested in
> implementing OMEMO but *can't* due to licensing issues. The original
> criticism of lacking specification is resolved. The spec is public domain,
> and it contains everything you need to roll your own library. But
> apparently, the goalposts have moved, and we now also require a permissively
> licensed implementation.
>

I would feel more sympathy in this if there were another
implementation. But it looks rather strongly as if every extant
implementation of OMEMO is simply a wrapper around a single crypto
implementation. So while "can't" is technically untrue, "won't" seems
very much to be the case.

In any standards organisation, we want to build specifications that
can yield independent, interoperable implementations. OMEMO has,
inarguably, failed to do so due to reliance on some odd cryptographic
primitives.

> Yes, it's true that there's currently no such thing for XEdDSA, but is this
> actually a concrete problem for anyone? As far as I'm aware, this has always
> been a purely hypothetical debate. If I'm wrong here, please speak up! In
> any case, when it comes down to it, implementing this yourself really isn't
> that complex. You can re-use existing EdDSA code, all you need to do is
> write the key conversion code yourself, for which there is pseudo-code in
> the standard, which maps fairly directly to well-known mathematical
> primitives, for which you can also re-use existing code. The main novel idea
> in XEdDSA is resolving an ambiguity in the conversion by forcing a sign bit
> to 0, and that's about it. Your code doesn't have to be constant-time and if
> you do it wrong, the signature just won't verify. I agree that it's never
> ideal to have to do stuff like this yourself, but this also isn't quite as
> "playing with fire" as some folks are making it out to be. In any case, I
> really doubt that this is the one big thing that would hinder such
> hypothetical implementors from adopting OMEMO.
>

And yet:

a) There are NO implementations which are written independently.

b) There are, on the other hand, people who have said they'd like to
implement, but won't.

So you can doubt as much as you like, but the facts remain that there
are no implementations of OMEMO which are not built on libsignal, and
no implementations of OMEMO which are not GPL.

Your counter-argument seems to be that the reasons for this are...
because people are lazy? Stupid? Because... What?

> To make a long story short, I remain unconvinced that switching to OLM makes
> sense at this point. The way I see it, moving forward with that amounts to
> preventing some inconvenience for an entirely hypothetical set of
> implementors at the cost of screwing over an entire existing, working
> ecosystem.
>

You keep using the word "hypothetical". I do not think it means what
you think it means.

I've met Remko, and I can assure you he is a real person. If he is
your hypothesis, then I can assure you he can be proven to exist.

> It's easy to throw around things like "it's experimental, so we can mess
> with it however we like and client devs will just have to deal with it",
> especially if you have no skin in the game. But for the stakeholders who are
> actually working on and using the technology, stuff like this is a huge
> deal. OMEMO is a pretty successful and established protocol at this point,
> and to be honest I just don't see the major 

Re: [Standards] OMEMO and Olm

[Remko Tronçon]

On 24 May 2017 at 22:55, Andreas Straub  wrote:

> Yes, it's true that there's currently no such thing for XEdDSA, but is
> this actually a concrete problem for anyone?


Yes. I obviously can't speak for all the other clients that currently don't
support OMEMO, but for Swift, XEdDSA is blocking OMEMO support for both
technical and legal reasons.


>  implementing this yourself really isn't that complex. You can re-use
> existing EdDSA code, all you need to do is write the key conversion code
> yourself, for which there is pseudo-code in the standard, which maps fairly
> directly to well-known mathematical for which you can also re-use existing
> code. The main novel idea in XEdDSA is resolving an ambiguity in the
> conversion by forcing a sign bit to 0, and that's about it.


I think this is oversimplifying things. It's the same as saying
implementing DH yourself is also fine, because it's just taking the modulo
of 2 integers. Also, "reusing existing code" is also not something every
piece of software takes lightly.

> I just don't see the major implementations switching over any time soon

I have serious doubts that at least one of them won't have to do *some*
significant work to get rid of the libsignal dependency to be legally in
order, which will mean implementing the ratchet and XEdDSA itself (unless a
library emerges that implements this all from scratch).

regards,
Remko
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___