[OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages

[Ian Goldberg]

On Tue, Jan 25, 2005 at 11:26:28PM -0600, Evan Schoenberg wrote:
> Two situations, and associated questions: 
> 
> 1) 
> - My friend and I are chatting via OTR 
> - I disconnect. I reconnect (same application session).  We can 
> continue chatting as before. 
> - I disconnect and quit. 
> - I relaunch the application and connect.  I open a message window to 
> my friend and send him a normal (unencrypted) message, not realizing he 
> has remained connected and not hit stopped the OTR session. 
> - I receive:  ?OTR Error: You sent unencrypted data to <name>, who was 
> expecting encrypted messages from you. 
> 
> Question: Should a client disconnect all OTR sessions on an account 
> when that account disconnects? And from my friend's perspective, should 
> a client disconnect an OTR session when the target contact disconnects? 

Not all IM networks tell you when someone you're talking to logs off,
unfortunately.  :-(  Since the failure mode is minimal (your message
gets through to him anyway), it's probably not a big deal.

> 2) 
> - My friend decides to cancel the OTR session without telling me. 
> - I send a message 
> - I receive: ?OTR Error: You sent encrypted data to <name>, who wasn't 
> expecting it. 
> 
> Question: Is there a way in which the protocol could be expended to 
> send some sort of otr-specific message to the other side letting it 
> know that one person has asked to end the session? 

No, and that's quite on purpose.  There should be NO WAY a network
message can cause a session to transition from private to not private.
If there were, you'd have to be really, really careful about whether
that message is authentic / replayed / etc.  There's also the problem
of: 1. user (in secure conversation) starts typing private message,
2. other side ends the session, sending "session ended" packet to user
3. User hits Enter to send his message in the (now unencrypted) session.

It's really important that the user have to take non-trivial action to
leave a private conversation.

   - Ian