[OTR-dev] session termination

Donny Viszneki donny.viszneki at gmail.com
Thu May 31 16:38:15 EDT 2007


TWICE I thought I had sent this to the list, and twice I had only sent
it to individual posters on the mailing list ("reply ot all" was the
default reply behavior on my previous mail client.)

> Currently the miranda plugin is using the alternative method and does not
> send an OTR termination message when going offline (which is the source of
> the bug).

I wouldn't necessarily describe this as a "bug," nor would I describe
the miranda plugin as the source of it. I would describe this as an
acceptable, even preferable, design limitation of OTR. The real
"source" of the problem is -- it seems to me -- latency and/or
unavailability of the networking substrate underlying the channel over
which both encrypted discussion, and negotiation of discussion
sessions take place. In the case of OTR, this is usually an instant
messaging service, but it's worth noting that in actuality it could be
any medium over which arbitrary text can be exchanged between users.

Consider this: What if a Miranda user is suddenly disconnected from
their instant messaging service or the internet? What if your client
or computer crashes? What happens to encrypted messages that are sent
to you?

Case 1: If the IM service doesn't wait for any sort of message
receipt, those messages disappear into the ether (this is the case on
AOL/AIM, and IRC.)
Case 2: The IM service does expect a message receipt, and eventually
returns an error to the sender of the message, telling them that their
message didn't make it.
Case 3: The IM service both waits for message receipt, AND queues its
users' messages for them so that they can receive messages sent in
their absence once they reconnect. (This is the case on many Jabber
servers. GTalk once was case 1, now it too is case 3. And ICQ was once
case 3, but I don't know what they do since AOL got them.)

The common occurance of this "error" is caused by a Case 3 service, in
this type of service there exists a unique potential for extreme
latency on the networking substrate. It happens because you end up
with an asymmetrical OTR state between two individuals; that is, one
user believes there is still an OTR session, and the other user does
not. I get these "Unreadable message" errors about a couple times a
week using Jabber, and I accept it because I _understand_ three
things:

One, that on a Case 1 IM service the unreadable OTR messages will
simply disappear into the ether.
Two, that OTR is itself a sort of point-to-point IM service tunneled
through another IM service.
Three, that this message ought to have disappeared into the ether,
because OTR is -- for good reason -- not a Case 3 service.

So what seems like an error message is actually just extra
information: on most Case 1 services you simply would never have known
that a message was sent to you that never got there because you
weren't connected at the time. But because OTR is privy to the fact
that there WAS a message that was lost, it tells you so. And most
people don't understand that it's not an error, it's just extra
information.

I believe that making OTR a case 2 service is not out of the question.
Perhaps OTR should be able to report to the user whether or not their
messages are actually being received. This simply means waiting for an
ACK after each message is sent.

Some questions that may be relevant that I don't know the answer to:
Can OTR messages during an encrypted session be received out of order?
Will the messages be readable? Will OTR notice that they are out of
order?

I think a case 3 situation for OTR would be very inadvisable. To have
OTR cache outgoing private messages so that it can re-deliver them in
a possible future session in case they accidentally lost the current
one seems to me to be a dangerous idea, counterproductive to the goal
of privacy.

In short, yes it is nice when OTR reacts when I disconnect from my IM
services by telling my friends to end their OTR sessions. But because
of complications that have already been mentioned on this mailing list
(you don't receive "buddy-online" notifications for everyone you might
want to use OTR with,) it really only helps avoid a very small number
of "unreadable message" "errors."

Best Solution, IMHO:

Include an explanatory hyperlink, a la:
(05:03:16 PM) <a
href="http://otr-help.cypherpunks.ca/unverified.php">Unverified</a>
conversation with someuser started.

On 5/31/07, Marti Raudsepp <marti at juffo.org> wrote:
> On 5/30/07, Joseph Elwell <jelwell at singleclick.com> wrote:
> > It's as if the Mac has the port stuck and won't
> > let OTR Proxy have access to the port.
>
> I haven't followed the rest of this discussion, but this problem seems
> similar to what happens on Linux -- connections will remain in
> TIME_WAIT state for some time after they have been disconnected, and
> this prevents programs from binding to any of the ports used by the
> connection. There's a cure for it -- SO_REUSEADDR.
>
> If you can be bothered, you might want to try if setting it before
> binding the socket.
>
> Marti
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>



More information about the OTR-dev mailing list