[OTR-dev] OTRv3 instance tag and session switching

[M. D.]

 Hello again,

 >I'm not sure what you mean by this.  Alice's OTR software will see one
 >Commit message with sender tag 0x102 and one with tag 0x103.  It will
 >then send one Key message with sender 0x101 and receiver 0x102, and one
 >Key message with sending 0x101 and receiver 0x103.  The two key
 >exchanges will proceed entirely independently, and Alice will end up
 >with two ConnContexts (in libotr terms), one for each of Bob1 and Bob2.

Okay, so Alice has two ConnContexts... What is going to happen if Alice receive an Error Message or Query Message? They do not contain instance tags so which one of Alice's two ConnContexts will handle the message?

I think these are details that are worth mentioning in the protocol draft.

Regards,
Marin


 >-------- Оригинално писмо --------
 >От:  Ian Goldberg 
 >Относно: Re: [OTR-dev] OTRv3 instance tag and session switching
 >До: otr-dev at lists.cypherpunks.ca
 >Изпратено на: Неделя, 2013, Декември 8 18:12:19 EET
 >
 >
 >On Fri, Dec 06, 2013 at 05:35:31PM +0200, Marin Dzhigarov wrote:
 >>  >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.
 >
 >Right.
 >
 >> Does Alice still keep Bob1's instance tag?
 >
 >I'm not sure what you mean by this.  Alice's OTR software will see one
 >Commit message with sender tag 0x102 and one with tag 0x103.  It will
 >then send one Key message with sender 0x101 and receiver 0x102, and one
 >Key message with sending 0x101 and receiver 0x103.  The two key
 >exchanges will proceed entirely independently, and Alice will end up
 >with two ConnContexts (in libotr terms), one for each of Bob1 and Bob2.
 >
 >> 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.
 >
 >Yes, that is correct.
 >
 >> Does this make any sense? 
 >
 >It sounds like you have it right.
 >
 >> Thanks in advance for the help!
 >
 >No problem.  Do ask if you have more questions; we're happy to help!
 >
 >   - Ian
 >_______________________________________________
 >OTR-dev mailing list
 >OTR-dev at lists.cypherpunks.ca
 >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
 >