On 10/10/14 23:09, Trevor Perrin wrote: > On Fri, Oct 10, 2014 at 1:21 PM, Ximin Luo <[email protected]> wrote: >> On 10/10/14 21:06, Trevor Perrin wrote: >>> >>> It's true that the asynchronous setting requires a message to be >>> stored somewhere, awaiting delivery. >>> >>> But I disagree that it's "not much effort" for this somewhere to >>> retransmit messages to anyone in a group who asks. That's not how >>> transports like (SMS, Google Cloud Messaging, email, Pond, or mix >>> networks) work. >>> >> >> Why do you think it's a lot of effort? Those transports don't try to achieve >> group consistency; why is it unreasonable to suppose that consistency >> requires changes to (or, enhancements on top of) how the transport works? > > Improving reliability is *already* a huge focus for any messaging system. > > Nonetheless, projects like TextSecure find themselves dealing with > unreliable message delivery. And even if it could be improved in some > transports, the protocol might be adapted to other transports where > it's harder. >
I believe that consistency (incrementally, of history) requires reliability. In other words, if reliability is too costly to achieve, then consistency (in that sense) is too costly to achieve. Sure, reliability is already a focus, which is why I think (what I propose) is not too much effort. I haven't seen any alternative models for consistency that are acceptable to me, that don't require reliability - such as the one being discussed below. >>> [1] https://moderncrypto.org/mail-archive/messaging/2014/000372.html >>> >> >> This [1] doesn't achieve consistency. I tried to explain why both in its >> "next message in thread" and in the first post of this thread, but it looks >> like my warnings are falling on deaf ears; here is a more concrete example: >> >> A: (1) Who wants ice cream? (last-message-seen: 0) >> A: (2) Who wants to kill the president? (last-message-seen: 1) (sent to >> everyone, *except B*) correction: *except C*; I believe Trevor took this into account >> B: (3) No thanks... (last-message-seen: 2) >> C: (4) Me! (last-message-seen: 3) > > Thanks for the concrete example. > > It would be great to have a list of cases like this so we could > compare how different proposals handle them. > > In this case, with Moxie's proposal, C is warned about the missing > message before saying "Yes!". The precise semantics of the warning would be "some previous ancestors, except direct parents, were not received". "Some" is correctly vague - *literally anything* could have been said before (2) - there is no way for C to know what. How can C respond to this? Either he waits until all ancestors have been received (which I suggest we enforce), or he writes a message without waiting - but then it is indistinguishable *to others* that he was missing those ancestors, since (4) says "last-message-seen: 3", which is exactly the same as if there was no attack (i.e. if C did receive (2)) [*]. I don't feel it's reasonable to let the user have to make this sort of security decision. Furthermore, the first option would be stupidly hard to manually achieve, even worse than trying to remember which keys you've validated in TextSecure (so perhaps I am trying to persuade the wrong people here - though buffering is free for users, but key validation isn't). So you are basically making the security decision on behalf of the user, and the warning is kind of pointless because probably not even I will take action on it. [*] An alternative is to specify that (4) should have a different last-message-seen pointer. But then, C still has actually seen message (3), and may refer to it semantically in the contents of (4), breaking user expectations. > And anyone reading the (obviously ambiguous) transcript could long-click on > C's "Yes!" and see what it's > responding to. > Um, how is this useful..? Anyone able to physically long-click on C's "Yes!" device, can just manually compare transcripts themselves. OTOH, anyone without physical access to C's device, does not know whether "(4) last-message-seen: 3" indicates that C missed anything before 3 or not. > Maybe that's good enough, maybe it's not. A better taxonomy of > possible issues and proposals would help make these comparisons. > Sure, a taxonomy is useful, but the reason I am *able* to come up with these scenarios is because of the reasoning I developed, that I tried to communicate in the first post. It would be nice if people stopped using me as an oracle and instead learnt the reasoning so that they can come up with their own test cases. :/ But fine, I get the point, I will try to produce test cases as well as reasoning in the future. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
