Re: [OTR-dev] Could OTR be made more fault-tolerant?
On 21/06/15 16:19, Jacek Wielemborek wrote: > Hi, > > (I'm sorry if this was already brought up - I had no idea which keywords > to pick when searching for such thread. Also, please CC me while > answering, I'm not subscribed to the mailing list) > > One of my friends constantly complains about OTR giving him no feedback > when he sends messages to me while I'm offline over XMPP (Pidgin). Then, > when I turn on the computer, I have no OTR session currently active and > all I'm getting is an error message that I got a message that I cannot > decrypt. This makes me ask him "what have you sent two days ago when I > was offline" at best and at worst, messages get lost. I'm getting the > impression that there should be support either from the library or the > UI to make this easier. > > Another problem that we are constantly getting is that when we try to > communicate after a few hours of inactivity, it often happens that one > of us switched between the machines (e.g. by suspending the laptop and > turning on the PC that also uses the same XMPP address) and the session > key is no longer valid. To avoid this, I usually manually refresh the > OTR session whenever significant amount of time passed, but I'm getting > the impression that I'm walking around a problem inherent to OTR. > > Perhaps there should be some "pinging" mechanism in place or when a > undecipherable message gets received, an error message should be sent? > The client could then discard such an error if he keeps a trusted > session on another channel, basically doing what I'm doing when the > problem happens. What do you guys think about this? > Hi, Jacek. Very good points! I don't think there is active work on extending the OTR protocol itself these days. However, I'm working on a secure group messaging protocol aiming for something like multiparty OTR. For this, I've also thought about the things you mention, because these problems get worse in larger groups. Hopefully "real soon now" an early version will be available to test/use on the MEGA chat platform. The system includes automatic (end-to-end) authenticated acks that people send after a timeout. (The timeout is to help efficiency - if the user was going to write something in response anyway, then this saves a lot of messages.) There is a similar feature in Pond, except that one must trigger it manually [1]. There are some security/usability tradeoffs between the manual/automatic approach, which could do with some research, but is outside of the typical "secure group messaging" goals and threat models - so I haven't spent too much time on it yet myself. Other nice security properties that we achieve (using the same technique as the auto-acks) is the guarantee that no messages were dropped during your session, and that messages are displayed in some sort of topological order, neither of which are guaranteed by OTR. We do these acks at the cryptographic level; XMPP pings are not useful *from a security point of view* because the transport (i.e. the server or your ISP infrastructure, if the transport isn't even protected) can always send fake unauthenticated acks. We would also like to add some feature along the lines of an auto-refresh / auto-join when other members leave and rejoin the transport channel, on the assumption that they have lost all previous cryptographic session material, but haven't yet worked out the best way to do this. The technical background on this is here [2], but it builds on top of quite a lot of other material. If you are interested in doing further work in this area, let me know and we can have a more detailed chat about it. X [1] https://pond.imperialviolet.org/ [2] https://github.com/infinity0/msg-notes/blob/master/appendix/05-hybrid.rst#corner-cases-caused-by-partial-visibility -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
On Sun, Jun 21, 2015, at 10:22 AM, Jacek Wielemborek wrote: > Perhaps there should be some "pinging" mechanism in place or when a > undecipherable message gets received, an error message should be sent? > The client could then discard such an error if he keeps a trusted > session on another channel, basically doing what I'm doing when the > problem happens. What do you guys think about this? With ChatSecure, we handle this using XMPP message delivery receipts, so that both ends absolutely know when the message has been received or not through a visual checkmark or X. We also transparently handle session refresh, so that if you move between devices during an OTR chat, or if one side comes online while the other-side is trying to send it a message, the OTR session will refresh, and the queued message will be delivered. Finally, in our v14.2 release coming out this week, you can set your OTR session to "FORCE", and we will queue all outbound messages until a valid OTR session is enabled. While Ximin and other's work on next-generation message protocols is important, I think the current OTR+XMPP is quite capable, but just poorly implemented by most apps from a usability and user experience perspective. +n -- Nathan of Guardian nat...@guardianproject.info ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
W dniu 22.06.2015 o 04:08, Nathan of Guardian pisze: > > > On Sun, Jun 21, 2015, at 10:22 AM, Jacek Wielemborek wrote: >> Perhaps there should be some "pinging" mechanism in place or when a >> undecipherable message gets received, an error message should be sent? >> The client could then discard such an error if he keeps a trusted >> session on another channel, basically doing what I'm doing when the >> problem happens. What do you guys think about this? > > With ChatSecure, we handle this using XMPP message delivery receipts, so > that both ends absolutely know when the message has been received or not > through a visual checkmark or X. We also transparently handle session > refresh, so that if you move between devices during an OTR chat, or if > one side comes online while the other-side is trying to send it a > message, the OTR session will refresh, and the queued message will be > delivered. Finally, in our v14.2 release coming out this week, you can > set your OTR session to "FORCE", and we will queue all outbound messages > until a valid OTR session is enabled. > > While Ximin and other's work on next-generation message protocols is > important, I think the current OTR+XMPP is quite capable, but just > poorly implemented by most apps from a usability and user experience > perspective. > > +n > The question is whether this is a protocol or front-end issue. How much work would it take to call what you implemented in ChatSecure as a new version of OTR and somehow get it integrated with the upstream? signature.asc Description: OpenPGP digital signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
On Mon, Jun 22, 2015 at 10:16:23AM +0200, Jacek Wielemborek wrote: > W dniu 22.06.2015 o 04:08, Nathan of Guardian pisze: > > > > > > On Sun, Jun 21, 2015, at 10:22 AM, Jacek Wielemborek wrote: > >> Perhaps there should be some "pinging" mechanism in place or when a > >> undecipherable message gets received, an error message should be sent? > >> The client could then discard such an error if he keeps a trusted > >> session on another channel, basically doing what I'm doing when the > >> problem happens. What do you guys think about this? > > > > With ChatSecure, we handle this using XMPP message delivery receipts, so > > that both ends absolutely know when the message has been received or not > > through a visual checkmark or X. We also transparently handle session > > refresh, so that if you move between devices during an OTR chat, or if > > one side comes online while the other-side is trying to send it a > > message, the OTR session will refresh, and the queued message will be > > delivered. Finally, in our v14.2 release coming out this week, you can > > set your OTR session to "FORCE", and we will queue all outbound messages > > until a valid OTR session is enabled. > > > > While Ximin and other's work on next-generation message protocols is > > important, I think the current OTR+XMPP is quite capable, but just > > poorly implemented by most apps from a usability and user experience > > perspective. > > > > +n > > > > The question is whether this is a protocol or front-end issue. How much > work would it take to call what you implemented in ChatSecure as a new > version of OTR and somehow get it integrated with the upstream? The OTR protocol doesn't get to know things about the IM network protocol (such as AIM, XMPP, etc.), so XMPP-specific details like message delivery receipts aren't appropriate for the base OTR layer. - Ian ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
On Sun, Jun 21, 2015 at 7:36 PM, Ximin Luo wrote: > Hopefully "real soon now" an early version will be available to test/use on > the MEGA chat platform. Curious, how or why will it be in the MEGA chat platform? Is it an independent extension or are you collaborating with MEGA? ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
W dniu 22.06.2015 o 12:17, Ian Goldberg pisze: > On Mon, Jun 22, 2015 at 10:16:23AM +0200, Jacek Wielemborek wrote: >> W dniu 22.06.2015 o 04:08, Nathan of Guardian pisze: >>> >>> >>> On Sun, Jun 21, 2015, at 10:22 AM, Jacek Wielemborek wrote: Perhaps there should be some "pinging" mechanism in place or when a undecipherable message gets received, an error message should be sent? The client could then discard such an error if he keeps a trusted session on another channel, basically doing what I'm doing when the problem happens. What do you guys think about this? >>> >>> With ChatSecure, we handle this using XMPP message delivery receipts, so >>> that both ends absolutely know when the message has been received or not >>> through a visual checkmark or X. We also transparently handle session >>> refresh, so that if you move between devices during an OTR chat, or if >>> one side comes online while the other-side is trying to send it a >>> message, the OTR session will refresh, and the queued message will be >>> delivered. Finally, in our v14.2 release coming out this week, you can >>> set your OTR session to "FORCE", and we will queue all outbound messages >>> until a valid OTR session is enabled. >>> >>> While Ximin and other's work on next-generation message protocols is >>> important, I think the current OTR+XMPP is quite capable, but just >>> poorly implemented by most apps from a usability and user experience >>> perspective. >>> >>> +n >>> >> >> The question is whether this is a protocol or front-end issue. How much >> work would it take to call what you implemented in ChatSecure as a new >> version of OTR and somehow get it integrated with the upstream? > > The OTR protocol doesn't get to know things about the IM network > protocol (such as AIM, XMPP, etc.), so XMPP-specific details like > message delivery receipts aren't appropriate for the base OTR layer. > >- Ian Okay, but on the other hand, this is a problem likely to hit any transport layer regardless of whether it's AIM, XMPP or something else as long as it is possible that the client software would be restarted. I believe that OTR should handle that. Also, doesn't OTR already have the capability to not only act as a filter (encrypting messages), but also send those on their own by communicating to the backend? signature.asc Description: OpenPGP digital signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
On 22/06/15 12:19, Carsten Mattner wrote: > On Sun, Jun 21, 2015 at 7:36 PM, Ximin Luo wrote: >> Hopefully "real soon now" an early version will be available to test/use on >> the MEGA chat platform. > > Curious, how or why will it be in the MEGA chat platform? > Is it an independent extension or are you collaborating with MEGA? > I work for MEGA; it will be released as a standalone free open source JS library around the same time that it's linked into their web platform. The protocol requires (but verifies, i.e. does not assume) that the transport meet certain properties but is otherwise agnostic to it, like OTR. Acks are essentially just an empty message, like in Pond, and don't require transport-level support. - echoes the same linear order of events (join/part/messages) back to everyone - channel members are known at all times, for each event - the server is responsible for attempting reliable point-to-point delivery, i.e. if it claims "A is in the channel at event M" then it is responsible for actively attempting reliable delivery of M to A, even in the presence of a dodgy connection between S and A. (However, we have passive and retroactive checks that this actually happens.) XMPP is supposed to meet these, but IRC (I believe) isn't. It's still a WIP to research in detail whether this is true in practise, and how imperfections of the transport affect the overall experience at the user level. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
(resending to a more suitable set of people) On 22/06/15 12:19, Carsten Mattner wrote: > On Sun, Jun 21, 2015 at 7:36 PM, Ximin Luo wrote: >> Hopefully "real soon now" an early version will be available to test/use on >> the MEGA chat platform. > > Curious, how or why will it be in the MEGA chat platform? > Is it an independent extension or are you collaborating with MEGA? > I work for MEGA; it will be released as a standalone free open source JS library around the same time that it's linked into their web platform. The protocol requires (but verifies, i.e. does not assume) that the transport meet certain properties but is otherwise agnostic to it, like OTR. Acks are essentially just an empty message, like in Pond, and don't require transport-level support. - echoes the same linear order of events (join/part/messages) back to everyone - channel members are known at all times, for each event - the server is responsible for attempting reliable point-to-point delivery, i.e. if it claims "A is in the channel at event M" then it is responsible for actively attempting reliable delivery of M to A, even in the presence of a dodgy connection between S and A. (However, we have passive and retroactive checks that this actually happens.) XMPP is supposed to meet these, but IRC (I believe) isn't. It's still a WIP to research in detail whether this is true in practise, and how imperfections of the transport affect the overall experience at the user level. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Could OTR be made more fault-tolerant?
Ian Goldberg writes: > On Mon, Jun 22, 2015 at 10:16:23AM +0200, Jacek Wielemborek wrote: >> W dniu 22.06.2015 o 04:08, Nathan of Guardian pisze: >> > >> > With ChatSecure, we handle this using XMPP message delivery receipts, so >> > that both ends absolutely know when the message has been received or not >> > through a visual checkmark or X. We also transparently handle session >> > refresh, so that if you move between devices during an OTR chat, or if >> > one side comes online while the other-side is trying to send it a >> > message, the OTR session will refresh, and the queued message will be >> > delivered. Finally, in our v14.2 release coming out this week, you can >> > set your OTR session to "FORCE", and we will queue all outbound messages >> > until a valid OTR session is enabled. >> > >> > While Ximin and other's work on next-generation message protocols is >> > important, I think the current OTR+XMPP is quite capable, but just >> > poorly implemented by most apps from a usability and user experience >> > perspective. >> > >> > +n >> >> The question is whether this is a protocol or front-end issue. How much >> work would it take to call what you implemented in ChatSecure as a new >> version of OTR and somehow get it integrated with the upstream? > > The OTR protocol doesn't get to know things about the IM network > protocol (such as AIM, XMPP, etc.), so XMPP-specific details like > message delivery receipts aren't appropriate for the base OTR layer. It might be nice to have the equivalent of an RFC addressing OTR/XMPP integration in terms of best practices. I can see your point about that being out of scope for OTR proper, but it also seems like struggling in code for each of N XMPP implementations isn't the right place either. pgpJcW589V5kY.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
