[OTR-dev] OTRv3 instance tag and session switching

[Marin Dzhigarov]

 >Pidgin keeps separate state when it sees different *sender* instance
>tags.
I thought so... But this is not specified in the protocol and as an OTR entusiast I'm curious how it is done.

Please follow this scenario:

______________________
Suppose Alice and Bob1 are under MSGSTATE_ENCRYPTED; They both have set ERROR_START_AKE and SEND_WHITESPACE_TAG
Alice has tag 0x00000101    and    Bob1 has tag 0x00000102;
Alice sends her Data Messages with [*sender* 0x00000101][*receiver* 0x00000102]
while Bob sends his with [*sender* 0x00000102][*receiver* 0x00000101]
______________________
But then Bob2 logs in from a different instance and has instance tag 0x00000103;
Bob2 is under MSGSTATE_PLAINTEXT
______________________
Alice sends an encrypted messages with [*sender* 0x00000101][*receiver* 0x00000102].
Both Bob1 and Bob2 receive it. Bob1 decrypts it and sees the message.
Bob2 is under MSGSTATE_PLAINTEXT so according to the OTR protocol he replies with an Error Message.
______________________
Alice receives Bob2's Error Message (it does not contain instance tags as it is not Encoded Message).
Alice sends V3 Query Message (because she has ERROR_STARTS_AKE)
______________________
Bob2 and Bob1 receive Alice's Query Message.
So now Bob1 and Bob2 are supposed to send D-H Commit Message to Alice

Bob1 already knows Alice's tag so it is possible for him to send D-H Commit Message with [*sender* 0x00000102][*receiver* 0x00000101]. So he does that.
However... Bob2 doesn't know Alice's tag so he can only send [*sender* 0x00000103][*receiver* 0x00000000]. So he does that.
______________________

Here comes the part that I do not quite understand...

Alice is receiving Bob1 and Bob2's D-H Commit Messages.
Does Alice still keep Bob1's instance tag? If yes - then she can respond to Bob1's D-H Commit Message with D-H Key Message with [*sender* 0x00000101][*receiver* 0x00000102]
What about Bob2's D-H Commit? If Alice still keeps Bob1's tag she can compare it to Bob2's tag that is in Bob2's D-H Commit Message and realise that Bob2 is actually Bob1 logged from a different instance. 
So Alice realises that Bob2 is a different *sender* and (if I understood correctly from your previous post) decides to create another session - with separate Message states, Authentication states and Policies especially for Bob2. Also, in this new session Alice will have her old tag 0x00000101 but she will send messages to 0x00000103.

Does this make any sense? 

Thanks in advance for the help!

Regards,
Marin
 >-------- Оригинално писмо --------
 >От:  Ian Goldberg 
 >Относно: Re: [OTR-dev] OTRv3 instance tag and session switching
 >До: otr-dev at lists.cypherpunks.ca
 >Изпратено на: Петък, 2013, Декември 6 16:39:41 EET
 >
 >
 >On Fri, Dec 06, 2013 at 10:24:07AM +0200, Marin Dzhigarov wrote:
 >>  Hello all,
 >> 
 >> I'm a developer who is trying to better understand the implementation behind the OTRv3 protocol and more specifically - the instance tags.
 >> According to the protocol draft:
 >> 
 >> "For version 3 messages, someone receiving a message with a recipient instance tag specified that does not equal their own should discard the message and optionally warn the user. The exception here is the D-H Commit Message where the recipient instance tag may be 0, indicating that no particular instance is specified."
 >> 
 >> In Pidgin, however, it does not seem that these messages are being discarded - seems to me that instead of discarding them Pidgin is somehow maintaining a separate session for every logged in instance and very session maintains its own Authentication state and Message state, keys, macs etc.
 >> 
 >> But that is not specified in the OTR protocol and I was wondering how is all of this accomplished? Are you doing something off the protocol?
 >> 
 >> Could someone please help me with that?
 >> 
 >> P.S (I'm not looking for code examples or anything like this, just the basic idea behind).
 >
 >Pidgin keeps separate state when it sees different *sender* instance
 >tags.  (Indeed, that's the whole point of the new instance tags.)  But
 >it discards received messages with unexpected *recipient* instance tags.
 >(Or at least it's supposed to be; are you seeing something different?)
 >
 >   - Ian
 >_______________________________________________
 >OTR-dev mailing list
 >OTR-dev at lists.cypherpunks.ca
 >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
 >