Re: [Standards] XEP-0313 adding archive id to live incoming messages
On 26 Jan 2015, at 13:14, Piotr Nosek piotr.no...@erlang-solutions.com wrote: I can't think of a way to definitely solve this right now but is it such a frequent case that you will send tons of messages to someone without a single answer and then reconnect repeatedly? It illustrates that you often need to do a sync that overwrites bits of the local archive, though. I’d really like a more robust solution than that. I’m hoping we’ll get there at the summit. Anyway I think it is essential to have some ID assigned by server (at least) in MAM. Even if clients would add proper IDs to the stanzas, the server might prefer an optimized ID types to enhance archive lookups, like a guarantee for them to be non-decreasing. Yes, the server has to be assigning UIDs for the messages as part of MAM as it stands. /K
Re: [Standards] XEP-0313 adding archive id to live incoming messages
On Mon, Jan 26, 2015 at 1:08 PM, Kevin Smith kevin.sm...@isode.com wrote: Please bottom-post on this list. On 26 Jan 2015, at 11:20, Piotr Nosek piotr.no...@erlang-solutions.com wrote: On Thu, Jan 22, 2015 at 2:47 PM, Kevin Smith kevin.sm...@isode.com wrote: On 22 Jan 2015, at 13:24, Georg Lukas ge...@op-co.de wrote: * Kevin Smith kevin.sm...@isode.com [2015-01-22 14:14]: How would you deduplicate a mix of messages received normally and MAM messages? Are you supposed to delete all normal messages when syncing up with MAM? Yep. Hmm. My gut feeling is that I don't particularly like that approach. Maybe we can really deprecate it with the unique-id idea. As I said earlier - if someone can come up with an alternative that works (in the edge cases, not just the obvious single-client case), I think speccing it would be great. No-one’s come up with such a proposal yet. But what are these edge cases actually? Can anyone write an example, a clear scenario that is problematic when using server-side IDs? A few examples (between server and client) of what happens if you try to use the local archive on a client to fill in gaps in received server archives (i.e. to not fetch server archives for periods the client was online). These are addressible, to different degrees, with sufficient amounts of client smarts, but not (I believe) all. The list of edge cases was longer than this, but these are the ones I can trivially remember: 1 server sends messageA 2 client sends messageB 3 client receives messageA 4 server receives messageB Client has the archive out of order I believe that the order of messages A B is not so relevant, since it is unlikely they are question and answer (we are observing race condition here). The order will be mixed until next sync, because the only archive ID the client has, are the ones from the messages received. So if the communication is interrupted at this point, the client will reconnect, query MAM for messages after messageA and will learn that from server perspective messageB should be after messageA, so the client can patch the local archive. If the conversation continues, the incorrect order will most likely persist in device memory but then again - how harmful for user experience it could probably be? 1 server sends messageA 2 client sends messageB 3 client receives messageA 4 client disconnects Client has a message in its archive that was never delivered. I believe XEP-0198 can deal with it and with SM enabled, the client shouldn't store the message in archive until the ack is received. 1) client sends messageA 2…26) client sends messageB…messageZ 3) session ends The client has to do a full sync anyway, because it doesn’t have IDs for any of its sent stanzas. /K I can't think of a way to definitely solve this right now but is it such a frequent case that you will send tons of messages to someone without a single answer and then reconnect repeatedly? Anyway I think it is essential to have some ID assigned by server (at least) in MAM. Even if clients would add proper IDs to the stanzas, the server might prefer an optimized ID types to enhance archive lookups, like a guarantee for them to be non-decreasing.
Re: [Standards] OTR
On 01/26/2015 01:49 AM, Bartosz Małkowski wrote: https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ A good read, thanks for posting. On 01/26/2015 04:10 AM, Georg Lukas wrote: c) it would be great to leverage this to secure file transfers / uploads as well as media streams. Since media streaming and file transfers are generally P2P, I think there are better ways of securing them (eg. TLS). The existing message encryption could be used to sign part of the TLS session construction if needed so that you could verify that the person you're receiving a file stream from is the same one you were talking with. —Sam P.S. I've been a bit out of the loop lately, as I've been travelling and interviewing for jobs, so I haven't been able to work on the current OTR usage XEP (I know I keep saying I'm going to get on that... or at least respond to my emails). Sorry about that. Related: If anyone from HipChat is on this list, I'll be in Austin next week interviewing with you guys; be sure to say hi and let's grab a coffee or something. -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com signature.asc Description: OpenPGP digital signature
Re: [Standards] OTR
* Bartosz Małkowski bmalkow...@tigase.pl [2015-01-26 07:58]: https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ This is a great writeup. Having multi-device end-to-end encryption with offline storage will significantly improve the security and usability of XMPP for normal people. I'd like to add some more points to the discussion though: a) it is important to allow security-conscious people to actually check the security properties, so the list of devices/keys/fingerprints needs to be exposed to power users, plus additional information messages when the list is extended. b) a protocol/approach for adding devices to the list needs to be created, maybe deploying some kind of cross-signing between one old and the new device? c) it would be great to leverage this to secure file transfers / uploads as well as media streams. d) multi-device end-to-end encryption can also elegantly solve the MUC security problem. Let's do it so. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: Digital signature
Re: [Standards] OTR
On 26 jan. 2015, at 10:10, Georg Lukas ge...@op-co.de wrote: * Bartosz Małkowski bmalkow...@tigase.pl [2015-01-26 07:58]: https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ Hi, Author of the post here, nice to see it’s already being discussed. This is a great writeup. Having multi-device end-to-end encryption with offline storage will significantly improve the security and usability of XMPP for normal people. I'd like to add some more points to the discussion though: a) it is important to allow security-conscious people to actually check the security properties, so the list of devices/keys/fingerprints needs to be exposed to power users, plus additional information messages when the list is extended. Agreed completely. b) a protocol/approach for adding devices to the list needs to be created, maybe deploying some kind of cross-signing between one old and the new device? Good point, I haven’t covered that, but adding new devices will indeed be more complicated than it is now. One way this could work is that you need one of the devices that already has a key on your account to bootstrap the new device (signing the new device's public key with its key). If the old device has some local logs, it could push some to the new device to still give it some backlog (re-encrypted with the new device’s key). But it does create a barrier for users. I know Firefox Sync did something like that (requiring you to input some characters from the browser on one device on the new one to add it to the sync), but apparently too many people didn’t like it, so it was removed. c) it would be great to leverage this to secure file transfers / uploads as well as media streams. If you just want to exchange one symmetric key, that should work fine. But using the protocol itself for filetransfers/media streams is likely going to give bad performance. d) multi-device end-to-end encryption can also elegantly solve the MUC security problem. Let's do it so. I don't think this solution will scale well to a group chat with more than ~10 people. The number of devices people have will likely be limited in practice, but the number of participants in a group chat can get quite large. I think there are better solutions for encrypting MUCs. Regards, Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
Wiadomość napisana przez Steffen Larsen zoo...@gmail.com w dniu 26 sty 2015, o godz. 09:19: A good discussion for the summit I would say. :-) :-) Indeed. Let decide something. I’m changing architecture of my XMPP library to allow easy extend it by any implementation of virtual xmpp streams :-) I will be able to add implementation of all e2e encryption protocols ;-) Regards! -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
A good discussion for the summit I would say. :-) /Steffen On 26 Jan 2015, at 07:49, Bartosz Małkowski bmalkow...@tigase.pl wrote: https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net
Re: [Standards] XEP-0313 adding archive id to live incoming messages
But what are these edge cases actually? Can anyone write an example, a clear scenario that is problematic when using server-side IDs? On Thu, Jan 22, 2015 at 2:47 PM, Kevin Smith kevin.sm...@isode.com wrote: On 22 Jan 2015, at 13:24, Georg Lukas ge...@op-co.de wrote: * Kevin Smith kevin.sm...@isode.com [2015-01-22 14:14]: How would you deduplicate a mix of messages received normally and MAM messages? Are you supposed to delete all normal messages when syncing up with MAM? Yep. Hmm. My gut feeling is that I don't particularly like that approach. Maybe we can really deprecate it with the unique-id idea. As I said earlier - if someone can come up with an alternative that works (in the edge cases, not just the obvious single-client case), I think speccing it would be great. No-one’s come up with such a proposal yet. /K
Re: [Standards] OTR
On 01/26/2015 09:19 AM, Steffen Larsen wrote: A good discussion for the summit I would say. :-) Thijs, Are you able to come to Brussels Thursday and/or Friday or to participate remotely one of these days? It would be really great to have your input in the e2e / OTR discussion at the summit. Winfried
Re: [Standards] XEP-0313 adding archive id to live incoming messages
Please bottom-post on this list. On 26 Jan 2015, at 11:20, Piotr Nosek piotr.no...@erlang-solutions.com wrote: On Thu, Jan 22, 2015 at 2:47 PM, Kevin Smith kevin.sm...@isode.com wrote: On 22 Jan 2015, at 13:24, Georg Lukas ge...@op-co.de wrote: * Kevin Smith kevin.sm...@isode.com [2015-01-22 14:14]: How would you deduplicate a mix of messages received normally and MAM messages? Are you supposed to delete all normal messages when syncing up with MAM? Yep. Hmm. My gut feeling is that I don't particularly like that approach. Maybe we can really deprecate it with the unique-id idea. As I said earlier - if someone can come up with an alternative that works (in the edge cases, not just the obvious single-client case), I think speccing it would be great. No-one’s come up with such a proposal yet. But what are these edge cases actually? Can anyone write an example, a clear scenario that is problematic when using server-side IDs? A few examples (between server and client) of what happens if you try to use the local archive on a client to fill in gaps in received server archives (i.e. to not fetch server archives for periods the client was online). These are addressible, to different degrees, with sufficient amounts of client smarts, but not (I believe) all. The list of edge cases was longer than this, but these are the ones I can trivially remember: 1 server sends messageA 2 client sends messageB 3 client receives messageA 4 server receives messageB Client has the archive out of order 1 server sends messageA 2 client sends messageB 3 client receives messageA 4 client disconnects Client has a message in its archive that was never delivered. 1) client sends messageA 2…26) client sends messageB…messageZ 3) session ends The client has to do a full sync anyway, because it doesn’t have IDs for any of its sent stanzas. /K
