From dlevin at cs.tu-berlin.de  Sun Aug  3 16:06:16 2008
From: dlevin at cs.tu-berlin.de (Dan Levin)
Date: Sun, 3 Aug 2008 22:06:16 +0200
Subject: [OTR-users] otr reliable, in-order messages
Message-ID: <308E4266-37C4-4BD6-BDAF-BDBE39E6B12A@cs.tu-berlin.de>

Hi fellow OTR users/devs,

Are there any plans to explore or implement guaranteed reliable, in- 
order message delivery in OTR? This would be a very valuable feature  
both from a security and reliability standpoint. If anyone knows of  
any work already done in this area, please let me know, otherwise any  
thoughts or comments would be welcome.

Thanks!
-Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20080803/fd4e59a6/attachment.bin>

From ian at cypherpunks.ca  Mon Aug  4 15:25:37 2008
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Mon, 4 Aug 2008 15:25:37 -0400
Subject: [OTR-users] otr reliable, in-order messages
In-Reply-To: <308E4266-37C4-4BD6-BDAF-BDBE39E6B12A@cs.tu-berlin.de>
References: <308E4266-37C4-4BD6-BDAF-BDBE39E6B12A@cs.tu-berlin.de>
Message-ID: <20080804192537.GZ18985@yoink.cs.uwaterloo.ca>

On Sun, Aug 03, 2008 at 10:06:16PM +0200, Dan Levin wrote:
> Hi fellow OTR users/devs,
> 
> Are there any plans to explore or implement guaranteed reliable, in- 
> order message delivery in OTR? This would be a very valuable feature  
> both from a security and reliability standpoint. If anyone knows of  
> any work already done in this area, please let me know, otherwise any  
> thoughts or comments would be welcome.

OTR leaves that up to the underlying IM network.  OTR assumes the
network already provides in-order delivery (doing IM when messages can
get reordered seems like something no IM provider would allow), but
allows for messages to be dropped (one party goes offline, messages are
dropped, etc.).

I don't think guaranteed delivery is even something we *want*, since if
your buddy is offline, that would imply there's a long-lived decryption
key somewhere, and that's defninitely undesirable.

   - Ian


From gmaxwell at gmail.com  Mon Aug  4 15:38:07 2008
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Mon, 4 Aug 2008 15:38:07 -0400
Subject: [OTR-users] otr reliable, in-order messages
In-Reply-To: <20080804192537.GZ18985@yoink.cs.uwaterloo.ca>
References: <308E4266-37C4-4BD6-BDAF-BDBE39E6B12A@cs.tu-berlin.de>
	<20080804192537.GZ18985@yoink.cs.uwaterloo.ca>
Message-ID: <e692861c0808041238n6dacf5cew942c2d6dc29979a8@mail.gmail.com>

On Mon, Aug 4, 2008 at 3:25 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Sun, Aug 03, 2008 at 10:06:16PM +0200, Dan Levin wrote:
>> Hi fellow OTR users/devs,
>>
>> Are there any plans to explore or implement guaranteed reliable, in-
>> order message delivery in OTR? This would be a very valuable feature
>> both from a security and reliability standpoint. If anyone knows of
>> any work already done in this area, please let me know, otherwise any
>> thoughts or comments would be welcome.
>
> OTR leaves that up to the underlying IM network.  OTR assumes the
> network already provides in-order delivery (doing IM when messages can
> get reordered seems like something no IM provider would allow), but
> allows for messages to be dropped (one party goes offline, messages are
> dropped, etc.).
>
> I don't think guaranteed delivery is even something we *want*, since if
> your buddy is offline, that would imply there's a long-lived decryption
> key somewhere, and that's defninitely undesirable.

OTR does already provide a useful property along these lines:  The
ability to get something like a negative acknowledgment.

A problem I have with some of my AIM contacts is that they'll fall
offline but appear to be online for some time.  By smacking refresh
connection I can see if their client is still around and differentiate
the human not responding case from the computer disconnected one.

Along those lines it might not be too unreasonable to make OTR
communicate back ID numbers of the last several received messages
anytime you send a message or refresh. Then your client would learn
which of your prior messages didn't make it.  I wouldn't go as far as
suggesting retransmission, but knowing which messages aren't going
through could be an enormous confusion reducer on unreliable links.