[OTR-dev] Flaw in OTR Protocol (with workaround!)

[Evan Schoenberg]

On Aug 4, 2005, at 9:09 AM, Ian Goldberg wrote:

>> This is exactly the behavior (modulo popup/inline issues) I'd like to
>> see for Private/Broken.  Essentially Private/Broken would force
>> "require OTR" policy.
>>
>
> What is different about what you want vs. the current "end private
> conversation" functionality?

If the other side went into a "Private/Broken" type state in response  
to receiving the packet sent after selecting "end private  
conversation" there would be no difference I can think of.  That's  
not the case at present:

Currently:
OTR session with Alice
I exit my client (without selecting End Private Conversation, which  
is what happens with most users)
I reconnect
Alice says something.  Her client is currently in the Private state,  
with the previous secure session.
I get an encrypted message I can't read (sent using the encryption  
from the old secure session).

Here's what I'd (and I believe Greg) would want to see:
OTR session with Alice
I exit my client (without selecting End Private Conversation, which  
is what happens with most users)
Alice's client is told that I ended the private conversation --  
mostly likely because the gaim-otr or other client plugin ends all  
private conversations before disconnecting or quitting.
I reconnect.
Alice says something.  Her client is currently in the "Private/ 
Broken" state -- it will not send in plaintext, but it knows the  
secure session is almost certainly invalid.
Alice's client automatically attempts to negotiate a new secure  
session.  If succesful, it "resends" the message (really sending it  
across the network for the first time), now encrypted with the new  
secure session.
I get an OTR Established message followed immediately by the  
encrypted message (sent using the encryption for the new secure  
session).

Does that make sense?

-Evan
www.adiumx.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20050804/237bd776/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20050804/237bd776/attachment.pgp>