Re: [Standards] Proposed changes to OMEMO's use of PEP

[Timothée Jaussoin]

Hi,
After reading all the discussions related to my pull request it seems that 
there is a consensus on the fact that PEP should not be used
this way to store those OMEMO bundles.I agree to retrieve it and continue with 
the current flow.
Regards,
Timothée Jaussoin 
Le lundi 03 avril 2017 à 07:18 +0200, Remko Tronçon a écrit :
> On 26 March 2017 at 00:01, Timothée Jaussoin  wrote:
> > This behavior can be fixed by setting pubsub#deliver_payloads to false in 
> > the 'urn:xmpp:omemo:0' node configuration. 
> 
> Bringing node configuration into a PEP-based protocol sounds like a slippery 
> slope, and is maybe taking it too far. Doesn't this also
> bring in extra complexity and questions like who configures the node and when?
> 
> The current split between data (which no one subscribes to) and metadata 
> (which is subscribed to) makes sense to me, and doesn't rely
> on anything but PEP semantics. This approach is also used in XEP-0084 (User 
> Avatar), which is probably the oldest PEP protocol out
> there.
> 
> Keeping this split seems independent from the discussion whether device IDs 
> (i.e. the metadata) should be published to separate
> items, and that the entire list can be queried for any new clients. XEP-0084 
> also publishes to different item IDs, although it
> doesn't rely on the entire list of metadata to be available, and if a server 
> doesn't support item IDs, avatars would still sort of
> work.
> 
> Remko
> 
> ___
> 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] Proposed changes to OMEMO's use of PEP

[Florian Schmaus]

On 03.04.2017 09:19, Remko Tronçon wrote:
> 
> On 3 April 2017 at 09:02, Florian Schmaus  > wrote:
> 
> Server side OMEMO support does not need to be mandatory to implement.
> 
> 
> Given that server-side support was suggested mostly as a way for client
> developers to write less code,

I guess we talk about different kinds of server-side support.

- 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] Proposed changes to OMEMO's use of PEP

[Remko Tronçon]

On 3 April 2017 at 09:02, Florian Schmaus  wrote:

> Server side OMEMO support does not need to be mandatory to implement.
>

Given that server-side support was suggested mostly as a way for client
developers to write less code, that would have the exact opposite effect.

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Florian Schmaus]

On 03.04.2017 08:09, Remko Tronçon wrote:
> On 26 March 2017 at 15:12, Andreas Straub  > wrote:
> So at that point, I have to ask myself, if we're already in this for
> the long haul, why not actually do it right, i.e. explicit server
> support?
> 
> Although involving the server in this would make things a bit easier on
> clients, I'm also concerned it brings more practical problems to rely on
> server availability than it solves. 
> ... it still makes clients rely on their server
> administrators to upgrade and enable this feature, which they may have
> less reason to for a purely end-to-end feature. Besides, for end-to-end
> encryption, relying on the server as little as possible sounds
> preferrable (although it shouldn't take away any security theoretically).

Server side OMEMO support does not need to be mandatory to implement.

- 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] Proposed changes to OMEMO's use of PEP

[Remko Tronçon]

On 26 March 2017 at 15:12, Andreas Straub  wrote:

> So even if we were to go this way, the timeline until we could in good
> conscience actually enable this change in the client is on the order of
> many, many months. Because I'm not about to break the protocol for my users.


The 'this breaks current users/implementations' argument seems to come up
regularly in OMEMO protocol discussions, and I don't understand why.
Current users have a protocol that works: eu.siacs.conversations.axolotl.
Nobody is changing that protocol, so it will work indefinitely. Existing
users will never be affected.

Until it reaches Draft (which can, and probably will indeed take months),
everyone should expect 'urn:xmpp:omemo:0' to get breaking changes
regularly. This is what 'Experimental' is for.

That said, in this case, the argument "The axolotol protocol covers more
*situations* than omemo:0" *is* a valid argument.

So at that point, I have to ask myself, if we're already in this for the
> long haul, why not actually do it right, i.e. explicit server support?


If it's a valid technical question to be asked, then it needs to be asked
now.

Although involving the server in this would make things a bit easier on
clients, I'm also concerned it brings more practical problems to rely on
server availability than it solves. As you said, even if server
implementors decide it is worth investing resources in implementing this
custom protocol, it still makes clients rely on their server administrators
to upgrade and enable this feature, which they may have less reason to for
a purely end-to-end feature. Besides, for end-to-end encryption, relying on
the server as little as possible sounds preferrable (although it shouldn't
take away any security theoretically).

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Remko Tronçon]

On 26 March 2017 at 00:01, Timothée Jaussoin  wrote:

> This behavior can be fixed by setting pubsub#deliver_payloads to false in
> the 'urn:xmpp:omemo:0' node configuration.
>

Bringing node configuration into a PEP-based protocol sounds like a
slippery slope, and is maybe taking it too far. Doesn't this also bring in
extra complexity and questions like who configures the node and when?

The current split between data (which no one subscribes to) and metadata
(which is subscribed to) makes sense to me, and doesn't rely on anything
but PEP semantics. This approach is also used in XEP-0084 (User Avatar),
which is probably the oldest PEP protocol out there.

Keeping this split seems independent from the discussion whether device IDs
(i.e. the metadata) should be published to separate items, and that the
entire list can be queried for any new clients. XEP-0084 also publishes to
different item IDs, although it doesn't rely on the entire list of metadata
to be available, and if a server doesn't support item IDs, avatars would
still sort of work.

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Andreas Straub]

Hi,

thanks for giving us your side of the story, Tim.


See https://xmpp.org/extensions/xep-0060.html#owner-configure.

This behavior can be fixed by setting pubsub#deliver_payloads to false in the 
'urn:xmpp:omemo:0' node configuration. The clients will
then only get a small notification and not the whole bundle anymore, it can 
then retrieve the bundle manually if he needs it. Again
here we are relying on features that already exists. I can complete my pull 
request to enforce this behavior on node creation.


So I guess you'd just get empty s with the id being the OMEMO 
device id then? That's nice. Is this supported everywhere?



This proposal is also internally inconsistent. Some of the
prescribed
behavior makes no sense under this new architecture (e.g. there is
no
point in explicitly fetching bundles anymore). It is also lacking
business rules describing how to handle the issues I raised above.



See above.


Where? This change would imply quite a few internal incosistencies. Most 
importantly, you haven't addressed the problem of what happens when the 
server doesn't support multiple items per node, or doesn't support as 
many entries as you need. You just kinda hand waved it as "people are 
working on it", but tbh that's not nearly good enough. So it just stops 
working then, right? A *ton* of people are using this protocol already, 
many of whom you'd be breaking this for. Even if this eventually makes 
it into releases of every major server software, operators out in the 
wild don't always update immediately to the newest version of everthing. 
In fact, it's actually really hard to get them to.


I know I'm repeating myself here, but you're not really acknowledging 
the very real consequences this change will have for a lot of users. 
This *will* break things, there's no way around it. So in the mean time, 
what are we supposed to tell users? Change servers? And all of this for 
what? A change that doesn't actually fix any real problems? IMO you 
really need to come up with a better justification for this than that it 
"feels more correct". That's not good enough.



Again a totally agree with you and your solution seems to be a perfect way to 
figure out this problem for now. But, with my proposal,
I'd like to make this XEP future proof (afaik the Prosody team is planning to 
implement the missing behavior in their future release)
and only relies on existing XEPs (PEP and Pubsub) techniques to makes the 
results more coherent and simple.


I don't really see how this change simplifies anything in any meaningful 
way. You still have to do all the same checks on the client that you had 
to do before. So what are we future proofing against here, exactly? What 
future effects are you anticipating that will break the current mechanism?



Also, I saw that the current OMEMO implementations (in Gajim and Conversations 
for now) are relying on the historical namespace
'eu.siacs.conversations.axolotl' that will break the day they move to the one 
defined in the official XEP. Because this can takes a bit
of time I prefer to address those architectural concerns now better than having 
to redefine it when we will have proper servers
supports.


In my view these are completely separate issues. One is something we 
have control over, because it's on the client. The other we don't, 
because the blocker are existing server deployments. If a user has a 
problem it's significantly easier to tell them to update their software, 
than to get their server operator to deploy updates. So I don't think 
it's sensible to say this needs to be done before the new OMEMO version 
comes out. Your change would be delaying the new version, because it 
couldn't be adopted before there is widespread support in existing 
server deployments for it.



The main point of my pull request is to try to keep XMPP coherent and relies on 
existing XEPs. If it brings implementations and support
issues, we can fix it on the servers and clients, if there is something unclear 
in the PEP XEP, we can also talk about it and try to
figure out why we have different point of views on this part of the extension.


It's easy for you to say "we can fix it on the clients and the servers" 
if you don't have any users that will be impacted by this. Getting 
existing server deployments to upgrade is just not that easy. Make no 
mistake, this will take time.


So even if we were to go this way, the timeline until we could in good 
conscience actually enable this change in the client is on the order of 
many, many months. Because I'm not about to break the protocol for my 
users. So at that point, I have to ask myself, if we're already in this 
for the long haul, why not actually do it right, i.e. explicit server 
support?


I'm still not convinced that's really needed, because experience tells 
me this isn't really a problem that needs fixing, but it's obviously the 
much better solution. If you actually wanted to "future proof" OMEMO, 
this is what y

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Daniel Gultsch]

Hi,

2017-03-25 6:41 GMT+01:00 Evgeny Khramtsov :

> Fri, 24 Mar 2017 17:03:36 +0100
> Andreas Straub  wrote:
>
> > If anything, we should maybe think about adding explicit
> > server-side support for OMEMO. I would be interested to hear what the
> > wider XMPP community thinks.
>
> As a server developer I don't like the idea and don't want to implement
> this in ejabberd, because I'm against OMEMO until basic problems with
> it are resolved (like full-text search, problems with losing
> keys/devices, etc).
>

Nobody asked you to implement it. Explicit server side support is just a
thought experiment that could help us clean up some edge cases and optimize
traffic. Thanks to namespace delegation we wouldn't even need to put this
into the server directly.

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Daniel Gultsch]

Hi,

2017-03-26 0:01 GMT+01:00 Timothée Jaussoin :

> Again a totally agree with you and your solution seems to be a perfect way
> to figure out this problem for now. But, with my proposal,
> I'd like to make this XEP future proof (afaik the Prosody team is planning
> to implement the missing behavior in their future release)
> and only relies on existing XEPs (PEP and Pubsub) techniques to makes the
> results more coherent and simple.
>

By making it 'future proof' you are preventing any real world use for the
foreseeable future.
Nobody argues that putting everything into one node is 'nicer'. However by
doing this change now you are making it impossible for any client with an
actual user base to implement it.
The XEP is a very deliberate compromise and everyone involved in the
creation was aware that it is a compromise from the beginning.

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Ruslan N. Marchenko]

On 26.03.2017 00:01, Timothée Jaussoin wrote:

Hi,

It seems that this pull request brought some interesting discussions.
I'll try to clarify my position regarding this pull request.

Le vendredi 24 mars 2017 à 17:03 +0100, Andreas Straub a écrit :

Hey all,

this topic has been discussed at the summit and in other venues
before,
and now a proposal to abolish the devicelist and move all bundles
into
separate items in a single PEP node has been submitted. I have raised
my
concerns in those abstract discussions in the past, but now we have
something concrete we can discuss.

https://github.com/xsf/xeps/pull/458/files

While I recognize that the way we've been using PEP is somewhat
unorthodox, I see several severe issues with this newly proposed
approach.

Most importantly, this change effectively relies on OPTIONAL/MAY
behavior in PEP. PEP/pubsub do not mandate that the server has to
keep
around more than one item per node. Therefore, this change will
limit
the number of OMEMO devices a user can have active at the same time
to
the maximum number of items per PEP node as supported by the server,
which in the general case has to be assumed to be 1. The devicelist
is
an absolutely essential component of OMEMO, and it *has to* work
properly. Without it, we not only lose multi-device, but have to
deal
with severe reliability issues related to whichever device(s)
happen(s)
to be currently announced or not (i.e. messages only arriving at
random,
possibly frequently changing subsets of devices without the user
being
able to control this at all)

I agree with that and I trully think that this behavior needs to be clarified. 
It seems indeed that this OPTIONAL/MAY in the PEP
extension brought two points of view on how PEP can be seen. To me, if a server 
can store several items per PEP nodes (which is the
case on several XMPP servers already) then I see it as a "Pubsub service" 
available under a user JID.
  
Also, some XEPs like Microblog (0277) and Pubsub-Subscription (0330) are already relying on it and are implemented in clients. The work

that we are currently doing to modernize the Bookmark XEP (0048) also replies 
on the fact that each bookmark will be store in different
items under the same PEP node (to prevent the current race-condition issue that 
we have today).

As I understood this behavior was mostly crafted like this because it was 
working on existing servers implementations, especially for
Prosody that doesn't support persistance of items in its current stable release.

My understanding of this subject from your similar discussion here 
https://mail.jabber.org/pipermail/standards/2017-January/031839.html is 
that the only protocol-compliant way to determine it is getting/setting 
max_items to be more than 1. Which means client needs to identify 
following features support - item-ids, persistent-items, config-node and 
then from the config get or set max_items to the required number.


Where _required number_ will in this particular case be equal to number 
of devices to support. To get number of devices you need to get current 
number of items and either find own item there or set to current+1 and 
add own item. Or it could be pre-set to certain _reasonable_ number, and 
if fully occupied - to execute certain garbage collector and prompt 
extension/cleanup from the user.


Now, do I understand it right that this particular sequence of events 
and decisions is suggested to be offloaded to the server side as being 
too complicated for client to perform?



Furthermore, by eliminating the indirection via a separate
devicelist
node and subscribing to all bundles directly, a significant increase
in
traffic overhead is to be expected. Any time a bundle changes, all
contacts will receive the entire bundle. This happens frequently in
OMEMO. For example, whenever a new session is established, according
to
the XEP, the responder SHOULD change their bundle (removing the used-
up
prekey). Clients might also rotate their signed prekey regularly.
Any
time these things happen, all OMEMO-enabled contacts (and other own
devices) will receive the full bundle. Note that in most cases,
these
clients don't care at all about these events. The only times a
client
would actually want to be passively informed about changes is when
devices are newly created or removed entirely, which is the vast
minority of these events. (For reference, bundles with the suggested
number of prekeys (100) are around 9-10kb in size.)


See https://xmpp.org/extensions/xep-0060.html#owner-configure.

This behavior can be fixed by setting pubsub#deliver_payloads to false in the 
'urn:xmpp:omemo:0' node configuration. The clients will
then only get a small notification and not the whole bundle anymore, it can 
then retrieve the bundle manually if he needs it. Again
here we are relying on features that already exists. I can complete my pull 
request to enforce this behavior on node creation.


This proposal is also internally inconsistent. Some of 

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Timothée Jaussoin]

Hi,

It seems that this pull request brought some interesting discussions.
I'll try to clarify my position regarding this pull request.

Le vendredi 24 mars 2017 à 17:03 +0100, Andreas Straub a écrit :
> Hey all,
> 
> this topic has been discussed at the summit and in other venues
> before, 
> and now a proposal to abolish the devicelist and move all bundles
> into 
> separate items in a single PEP node has been submitted. I have raised
> my 
> concerns in those abstract discussions in the past, but now we have 
> something concrete we can discuss.
> 
> https://github.com/xsf/xeps/pull/458/files
> 
> While I recognize that the way we've been using PEP is somewhat 
> unorthodox, I see several severe issues with this newly proposed
> approach.
> 
> Most importantly, this change effectively relies on OPTIONAL/MAY 
> behavior in PEP. PEP/pubsub do not mandate that the server has to
> keep 
> around more than one item per node. Therefore, this change will
> limit 
> the number of OMEMO devices a user can have active at the same time
> to 
> the maximum number of items per PEP node as supported by the server, 
> which in the general case has to be assumed to be 1. The devicelist
> is 
> an absolutely essential component of OMEMO, and it *has to* work 
> properly. Without it, we not only lose multi-device, but have to
> deal 
> with severe reliability issues related to whichever device(s)
> happen(s) 
> to be currently announced or not (i.e. messages only arriving at
> random, 
> possibly frequently changing subsets of devices without the user
> being 
> able to control this at all)
I agree with that and I trully think that this behavior needs to be clarified. 
It seems indeed that this OPTIONAL/MAY in the PEP
extension brought two points of view on how PEP can be seen. To me, if a server 
can store several items per PEP nodes (which is the
case on several XMPP servers already) then I see it as a "Pubsub service" 
available under a user JID.
 
Also, some XEPs like Microblog (0277) and Pubsub-Subscription (0330) are 
already relying on it and are implemented in clients. The work
that we are currently doing to modernize the Bookmark XEP (0048) also replies 
on the fact that each bookmark will be store in different
items under the same PEP node (to prevent the current race-condition issue that 
we have today).

As I understood this behavior was mostly crafted like this because it was 
working on existing servers implementations, especially for
Prosody that doesn't support persistance of items in its current stable release.


> 
> Furthermore, by eliminating the indirection via a separate
> devicelist 
> node and subscribing to all bundles directly, a significant increase
> in 
> traffic overhead is to be expected. Any time a bundle changes, all 
> contacts will receive the entire bundle. This happens frequently in 
> OMEMO. For example, whenever a new session is established, according
> to 
> the XEP, the responder SHOULD change their bundle (removing the used-
> up 
> prekey). Clients might also rotate their signed prekey regularly.
> Any 
> time these things happen, all OMEMO-enabled contacts (and other own 
> devices) will receive the full bundle. Note that in most cases,
> these 
> clients don't care at all about these events. The only times a
> client 
> would actually want to be passively informed about changes is when 
> devices are newly created or removed entirely, which is the vast 
> minority of these events. (For reference, bundles with the suggested 
> number of prekeys (100) are around 9-10kb in size.)
> 

See https://xmpp.org/extensions/xep-0060.html#owner-configure.

This behavior can be fixed by setting pubsub#deliver_payloads to false in the 
'urn:xmpp:omemo:0' node configuration. The clients will
then only get a small notification and not the whole bundle anymore, it can 
then retrieve the bundle manually if he needs it. Again
here we are relying on features that already exists. I can complete my pull 
request to enforce this behavior on node creation.

> This proposal is also internally inconsistent. Some of the
> prescribed 
> behavior makes no sense under this new architecture (e.g. there is
> no 
> point in explicitly fetching bundles anymore). It is also lacking 
> business rules describing how to handle the issues I raised above.
> 

See above.

> In theory, this change does eliminate contention on the devicelist. 
> Currently, announcing a device requires updating the devicelist to
> add 
> the new device, while retaining all old ones in the same item 
> ("read-update-write"), so there might be a situation where devices 
> overwrite one another if they both attempt to announce themselves at
> the 
> same time. But this really isn't as big of an issue as it may seem
> at 
> first. First of all, the odds of this happening are very slim.
> Devices 
> are not created anew or removed entirely very often in regular use.
> 
> There's also a really simple fix for this in the current XEP
> already: 

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Jonas Wielicki]

On Samstag, 25. März 2017 20:34:39 CET VanitasVitae wrote:
> OMEMO works perfectly fine without changes on the server side (apart from
> implementing PEP/PubSub of course), so I really don't get the reason of the
> discussion :/

Andreas suggested earlier that some of the awkwardness in the protocol arising 
from the use of PEP could be fixed with a few bits of server support.

kind regards,
jonas

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] Proposed changes to OMEMO's use of PEP

[VanitasVitae]

OMEMO works perfectly fine without changes on the server side (apart from 
implementing PEP/PubSub of course), so I really don't get the reason of the 
discussion :/

Am 25. März 2017 18:43:59 MEZ schrieb Evgeny Khramtsov :
>Sat, 25 Mar 2017 18:35:47 +0100
>Jonas Wielicki  wrote:
>
>> What’s your problem with another ejabberd developer implementing this
>> if they have interest in using that feature?
>
>I don't know about a core developer interested in OMEMO. This will be a
>contribution most likely. But then there is a problem with supporting
>contributed code.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Evgeny Khramtsov]

Sat, 25 Mar 2017 18:35:47 +0100
Jonas Wielicki  wrote:

> What’s your problem with another ejabberd developer implementing this
> if they have interest in using that feature?

I don't know about a core developer interested in OMEMO. This will be a
contribution most likely. But then there is a problem with supporting
contributed code.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Jonas Wielicki]

On Samstag, 25. März 2017 20:18:49 CET Evgeny Khramtsov wrote:
> > If your solution to Public-key cryptography UX Problems is to use no
> > encryption at all, it feels like you wasting our time.
> 
> LOL, but it's you who trying to waste my time because I (or another
> ejabberd developer) will have to implement this OMEMO stuff :)

What’s your problem with another ejabberd developer implementing this if they 
have interest in using that feature?

kind regards,
jonas


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] Proposed changes to OMEMO's use of PEP

[Evgeny Khramtsov]

Sat, 25 Mar 2017 16:45:34 +0100
Philipp Hörist  wrote:

> Its seems you dont like e2e encryption, and maybe you have no use
> case for it, but other people have obliviously as many people are
> using it.

So what's the problem? Use it.

> Thats only true if you only use one device. And thats intended as we
> dont want people that get our key to decrypt our Archive. its called
> Perfect Forward Secrecy.

Yeah, tell that a user when he loses his key. This will help him a
lot :)

> Also i dont see how your UX Problems with Public-key cryptography
> have any relevance here.

Well, browser developers resolved this UX problem by providing
preconfigured CA certificates, so a user doesn't need to decide. I
don't see how this is possible with OMEMO. And if it's not possible,
then, like someone said on the list before, "a protocol creating UX
problems is a bad protocol".

> If your solution to Public-key cryptography UX Problems is to use no
> encryption at all, it feels like you wasting our time.

LOL, but it's you who trying to waste my time because I (or another
ejabberd developer) will have to implement this OMEMO stuff :)
And I never said "not to use encryption at all".
I actually don't care as long as OMEMO is client developers burden.
That's why I typically silent on this topic.

> Whats your Agenda? Obviously you are not interested in e2e, so just
> dont use it.

My "agenda" is that I'm against putting OMEMO on the server for the
reasons I mentioned, that's it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Philipp Hörist]

Ok ..

Its seems you dont like e2e encryption, and maybe you have no use case for
it, but other people have obliviously as many people are using it.

> How to do this in MAM archive, server-side?

The Point of e2e is so that you cant search my messages on the server, you
bringing this up as a serious argument feels awkward.

> Then there is a little point in MAM

MAM is used to sync Messages between devices, so there is a big point in
using MAM.

> If I lose a single device I have (or it gets broken, whatever), I lose
> access to all my MAM messages, because I lose the key.

Thats only true if you only use one device. And thats intended as we dont
want people that get our key to decrypt our Archive. its called Perfect
Forward Secrecy.

Also i dont see how your UX Problems with Public-key cryptography have any
relevance here.
If your solution to Public-key cryptography UX Problems is to use no
encryption at all, it feels like you wasting our time.


Whats your Agenda? Obviously you are not interested in e2e, so just dont
use it.


2017-03-25 13:10 GMT+01:00 Evgeny Khramtsov :

> Sat, 25 Mar 2017 13:06:26 +0100
> VanitasVitae  wrote:
>
> > If you don't like the intention, then PGP is probably the way to go
> > for you.
>
> I'd better off not using e2e encryption at all: I don't have use cases
> for it.
> ___
> 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] Proposed changes to OMEMO's use of PEP

[Evgeny Khramtsov]

Sat, 25 Mar 2017 13:06:26 +0100
VanitasVitae  wrote:

> If you don't like the intention, then PGP is probably the way to go
> for you.

I'd better off not using e2e encryption at all: I don't have use cases
for it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[VanitasVitae]

If you don't like the intention, then PGP is probably the way to go for you.

MAM is used to sync messages in OMEMO. Its unorthodox, but still totally valid.

Am 25. März 2017 12:49:21 MEZ schrieb Evgeny Khramtsov :
>Sat, 25 Mar 2017 11:48:56 +0100
>VanitasVitae  wrote:
>
>> But that's intended
>
>Well I don't like this intention.
>
>> If you want to search through your messages, the only way is to do it
>> in your local archive
>
>Then there is a little point in MAM, because you still need to keep
>a local copy.
>
>> The UX is relatively independent from the protocol I'd say
>
>I would disagree. The "trust" is a fundamental property of all
>crypto stuff, they don't work without trust. But a user doesn't
>understand this (probably due to poor UX): s/he doesn't understand what
>are all these fingerprints/QR codes for. Browser developers have learnt
>that and don't ask a user about trust anymore.
>
>> QR codes are already a step in the right direction
>
>Not that much, users will still be puzzled, imho.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Evgeny Khramtsov]

Sat, 25 Mar 2017 11:48:56 +0100
VanitasVitae  wrote:

> But that's intended

Well I don't like this intention.

> If you want to search through your messages, the only way is to do it
> in your local archive

Then there is a little point in MAM, because you still need to keep
a local copy.

> The UX is relatively independent from the protocol I'd say

I would disagree. The "trust" is a fundamental property of all
crypto stuff, they don't work without trust. But a user doesn't
understand this (probably due to poor UX): s/he doesn't understand what
are all these fingerprints/QR codes for. Browser developers have learnt
that and don't ask a user about trust anymore.

> QR codes are already a step in the right direction

Not that much, users will still be puzzled, imho.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[VanitasVitae]

You cannot search Messages server side, that's true. But that's intended and I 
guess there is no way to achieve this while preserving forward and future 
secrecy. If you want to search through your messages, the only way is to do it 
in your local archive.

An interesting feature would be to enable a device to reencrypt messages for 
new device. That feature must not get triggered automatically though and should 
only be done from explicit user request. That way you could synchronize 
messages with devices that got registered after the messages have been sent.

The UX is relatively independent from the protocol I'd say. Yes, you should 
have the user manually trust contacts devices, but I guess there are more 
clever ways to do this rather than comparing the fingerprint (QR codes are 
already a step in the right direction, but I'd consider researching more in 
things like a web of trust or (as I once proposed in the mailing list) have 
transitive trust between a users devices).

Am 25. März 2017 10:50:02 MEZ schrieb Evgeny Khramtsov :
>Sat, 25 Mar 2017 08:43:34 +0100
>Philipp Hörist  wrote:
>
>> Can you go more into detail?
>> Why cant you search your OMEMO Messages?
>
>How to do this in MAM archive, server-side?
>
>> And what is the problem with losing a Device?
>
>If I lose a single device I have (or it gets broken, whatever), I lose
>access to all my MAM messages, because I lose the key.
>
>Another problem is UX: it's just terrible. Imagine an inexperienced
>user who sees something like "OMEMO fingerprint", or "Clean
>devices" (an example from Conversations). The first his question is
>"WTF
>is this???". This is the same problem as with PKIX certificates,
>like asking whether a user trusts a certificate or not: this just
>doesn't work.
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Evgeny Khramtsov]

Sat, 25 Mar 2017 08:43:34 +0100
Philipp Hörist  wrote:

> Can you go more into detail?
> Why cant you search your OMEMO Messages?

How to do this in MAM archive, server-side?

> And what is the problem with losing a Device?

If I lose a single device I have (or it gets broken, whatever), I lose
access to all my MAM messages, because I lose the key.

Another problem is UX: it's just terrible. Imagine an inexperienced
user who sees something like "OMEMO fingerprint", or "Clean
devices" (an example from Conversations). The first his question is "WTF
is this???". This is the same problem as with PKIX certificates,
like asking whether a user trusts a certificate or not: this just
doesn't work.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Philipp Hörist]

Can you go more into detail?
Why cant you search your OMEMO Messages?
And what is the problem with losing a Device?

2017-03-25 6:41 GMT+01:00 Evgeny Khramtsov :

> Fri, 24 Mar 2017 17:03:36 +0100
> Andreas Straub  wrote:
>
> > If anything, we should maybe think about adding explicit
> > server-side support for OMEMO. I would be interested to hear what the
> > wider XMPP community thinks.
>
> As a server developer I don't like the idea and don't want to implement
> this in ejabberd, because I'm against OMEMO until basic problems with
> it are resolved (like full-text search, problems with losing
> keys/devices, etc).
> ___
> 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] Proposed changes to OMEMO's use of PEP

[Evgeny Khramtsov]

Fri, 24 Mar 2017 17:03:36 +0100
Andreas Straub  wrote:

> If anything, we should maybe think about adding explicit 
> server-side support for OMEMO. I would be interested to hear what the 
> wider XMPP community thinks.

As a server developer I don't like the idea and don't want to implement
this in ejabberd, because I'm against OMEMO until basic problems with
it are resolved (like full-text search, problems with losing
keys/devices, etc).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Andreas Straub]

Hi,


I'm curious which server-side support for OMEMO you have in mind. Care
to elaborate?


So there are a few things about the PEP-based approach that are not 
ideal. The devicelist contention that the proposed change aims to 
address is really only one example of several scenarios where the client 
has to carefully manage the data in PEP by itself because the server 
doesn't act as anything more than a key/value store for our purposes.


It would be cool if we could have the server enforce some of the 
business logic for us, so that the client doesn't have to. Basically, 
the server would not only manage the devicelist more intelligently but 
also actually act like a X3DH key server[1].


Mostly, this would just entail offering more "atomic" primitives than is 
possible with PEP, e.g. publishing prekeys individually rather than 
having to overwrite the entire bundle. It would also only hand out any 
prekey once, so no two initiators could end up using the same prekey to 
build a session with the responder. The server could also assign device 
ids to new clients to prevent collisions there. Having some server-side 
constraints like this in place just makes life easier for the clients.


Some details would still have to be figured out, like whether we want 
the server to require some kind of proof from the client that it's 
actually "allowed" to publish/modify the data (signatures with the 
identity key or something?), or how to handle removing stale devices. 
But in essence, server-assisted OMEMO wouldn't look  all that different 
from what we have currently at all.


So as you can see, this wouldn't actually be a very complicated thing to 
implement, it's really just a few different IQ get/sets and some simple 
constraint checks. The bigger issue is going to be deployment, which is 
of course why we went with PEP in the first place...



[1] https://whispersystems.org/docs/specifications/x3dh/#roles
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Matthew Wild]

On 24 March 2017 at 16:03, Andreas Straub  wrote:
> In summary, I understand that the current behavior can seem strange at
> first, and I'm certainly not opposed to improving this in some way, I really
> don't think this proposal is the way to go here. It breaks the protocol. If
> anything, we should maybe think about adding explicit server-side support
> for OMEMO. I would be interested to hear what the wider XMPP community
> thinks.

As a server developer, I'd be +1 to such a move.

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Jonas Wielicki]

On Freitag, 24. März 2017 17:20:31 CET Florian Schmaus wrote:
> On 24.03.2017 17:03, Andreas Straub wrote:
> > If anything, we should maybe think about adding explicit
> > server-side support for OMEMO.
> 
> I'm curious which server-side support for OMEMO you have in mind. Care
> to elaborate?
> 
> And thanks for your extended discussion of PR #458. I agree with
> everything you wrote. Sadly the PR did not include any motivation and I
> don't remember the exact details from the discussion at the summit.
> Hence I still would love to hear the rationale behind it.

+1 to all of this (except that I wasn’t even at the summit and it would be 
great if I could still follow the discussion).

kind regards,
Jonas

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] Proposed changes to OMEMO's use of PEP

[Florian Schmaus]

On 24.03.2017 17:03, Andreas Straub wrote:
> If anything, we should maybe think about adding explicit
> server-side support for OMEMO.

I'm curious which server-side support for OMEMO you have in mind. Care
to elaborate?

And thanks for your extended discussion of PR #458. I agree with
everything you wrote. Sadly the PR did not include any motivation and I
don't remember the exact details from the discussion at the summit.
Hence I still would love to hear the rationale behind it.

- Florian




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

[Standards] Proposed changes to OMEMO's use of PEP

[Andreas Straub]

Hey all,

this topic has been discussed at the summit and in other venues before, 
and now a proposal to abolish the devicelist and move all bundles into 
separate items in a single PEP node has been submitted. I have raised my 
concerns in those abstract discussions in the past, but now we have 
something concrete we can discuss.


https://github.com/xsf/xeps/pull/458/files

While I recognize that the way we've been using PEP is somewhat 
unorthodox, I see several severe issues with this newly proposed approach.


Most importantly, this change effectively relies on OPTIONAL/MAY 
behavior in PEP. PEP/pubsub do not mandate that the server has to keep 
around more than one item per node. Therefore, this change will limit 
the number of OMEMO devices a user can have active at the same time to 
the maximum number of items per PEP node as supported by the server, 
which in the general case has to be assumed to be 1. The devicelist is 
an absolutely essential component of OMEMO, and it *has to* work 
properly. Without it, we not only lose multi-device, but have to deal 
with severe reliability issues related to whichever device(s) happen(s) 
to be currently announced or not (i.e. messages only arriving at random, 
possibly frequently changing subsets of devices without the user being 
able to control this at all)


Furthermore, by eliminating the indirection via a separate devicelist 
node and subscribing to all bundles directly, a significant increase in 
traffic overhead is to be expected. Any time a bundle changes, all 
contacts will receive the entire bundle. This happens frequently in 
OMEMO. For example, whenever a new session is established, according to 
the XEP, the responder SHOULD change their bundle (removing the used-up 
prekey). Clients might also rotate their signed prekey regularly. Any 
time these things happen, all OMEMO-enabled contacts (and other own 
devices) will receive the full bundle. Note that in most cases, these 
clients don't care at all about these events. The only times a client 
would actually want to be passively informed about changes is when 
devices are newly created or removed entirely, which is the vast 
minority of these events. (For reference, bundles with the suggested 
number of prekeys (100) are around 9-10kb in size.)


This proposal is also internally inconsistent. Some of the prescribed 
behavior makes no sense under this new architecture (e.g. there is no 
point in explicitly fetching bundles anymore). It is also lacking 
business rules describing how to handle the issues I raised above.


In theory, this change does eliminate contention on the devicelist. 
Currently, announcing a device requires updating the devicelist to add 
the new device, while retaining all old ones in the same item 
("read-update-write"), so there might be a situation where devices 
overwrite one another if they both attempt to announce themselves at the 
same time. But this really isn't as big of an issue as it may seem at 
first. First of all, the odds of this happening are very slim. Devices 
are not created anew or removed entirely very often in regular use.


There's also a really simple fix for this in the current XEP already: 
clients MUST check that their own device is included in the list 
whenever they receive an update for their own devicelist, and if not, 
add themselves again. We've been doing it this way for 1.5 years now, 
and not once has this caused a problem. But more importantly, this 
behaviour needs to be in the XEP regardless of this change, because 
clients have to ensure that they are currently announced at all times 
anyway, because there are numerous other reasons why a device might have 
been removed. So it's not like the proposed change would even simplify 
anything here.


What's more though, as I described above, the proposed change "fixes" 
this theoretical problem at the cost of possibly introducing contention 
on the bundles, which is actually a much worse problem. If the server 
can't retain several bundles at the same time, this is not something 
that the clients can fix by simply publishing again. Best case: you lose 
multi-device entirely, and whichever device has last published a bundle 
is the only one that can use OMEMO at any moment in time. Worst case: 
clients keep overwriting one another in order to re-announce themselves 
ad infinitum.


In summary, I understand that the current behavior can seem strange at 
first, and I'm certainly not opposed to improving this in some way, I 
really don't think this proposal is the way to go here. It breaks the 
protocol. If anything, we should maybe think about adding explicit 
server-side support for OMEMO. I would be interested to hear what the 
wider XMPP community thinks.


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