Define how to include query msg or tag on Phi
claucece opened this issue · comments
Maybe include a tag. Also, clarify how Phi works on each mode.
I'm unsure now why the tag was needed.. @olabini can you clarify?
As far as I remember, modes were designed to be per client. And that is why:
Take into account, that some clients might implement different modes when talking with each other. In
those cases:
* If a client implements "OTRv4-standalone" mode or "OTRv4-interactive-only" mode and a request for an OTRv3 conversation arrives, reject this request.
* If a client implements "OTRv4-interactive-only" mode and a request for an offline conversation arrives, reject this request.
The OTRv4 state machine will also need to know the mode in which is working on when initialized. It will also need to take this mode into account every time it makes a decision aound how to transition from every state.
Or we are now considering like policies per account?
Didn't this have to do with whether we had a query message or not - and when initiating in standalone mode, we don't have a query message, so we don't know what to include in phi. Or something like that. It wasn't about modes per se, but the standalone mode was the originator of the need, I think. This came from @cobratbq if I remember correctly.
My original question is related specifically to the Starting a conversation interactively section. I'm not sure if that means that it is only relevant to the OTRv4-interactive-only mode. (Note also that even if one client is in OTRv4-interactive-only mode, the other party may not be and I presume you'd still want to respond to this form initiation.)
The question is: Let's say we have remembered a query tag. It might be from the current session or from an earlier session, or from a session established for a different client on the same account, i.e. different instance tag.
Now I receive an Identity message. How can I figure out whether or not to use the remembered query tag when calculating phi? That is, how can I figure out what the intended mode is?
Ok.. first of all the query msg or whitespace tag are optional in phi, as it says:
or/and the query message or the whitespace tag
so they are not mandated to be included.
Note also that even if one client is in OTRv4-interactive-only mode, the other party may not be and I presume you'd still want to respond to this form initiation
Exactly. And that is why in the mode section (https://github.com/otrv4/otrv4/blob/master/otrv4.md#otrv4-modes) it says:
Take into account, that some clients might implement different modes when talking with each other. In those cases:
If a client implements "OTRv4-standalone" mode or "OTRv4-interactive-only" mode and a request for an OTRv3 conversation arrives, reject this request.
If a client implements "OTRv4-interactive-only" mode and a request for an offline conversation arrives, reject this request.
to know how to behave if you are in different modes.
The question is: Let's say we have remembered a query tag. It might be from the current session or from an earlier session, or from a session established for a different client on the same account, i.e. different instance tag.
If it is from an earlier session, idk why you will have it. Once it is used by phi, if needed, it is erased. If a new session starts, then it is set to NULL.
If it is from a session with a different instance tag, I think what you mean is:
- Alice sends a Query msg and saves it for phi
- Bob receives the query msg (saves it for phi) and sends an Identity msg (advertising his instance tag, and saving Alices instance tag).
- For some reason, Alice sends an Identity msg from a different instance tag to Bob.
- Bob sees that it is from a different instance tag, so this is a different session. Phi is set to null so far.
- Bob replies with an Auth-R message with phi not including any query as it is null.
- If Alice replies to Bob's Identity msg, she will include the query msg she sent for that session.
Phi is the same as the private ephemeral values. You don't store them for longer than a session. They are needed for the DAKE and end when the DAKE ends, even if there is another DAKE in another instance tag in progress. The only things that last longer than a session are long-term values and profiles.
That is, how can I figure out what the intended mode is?
I don't get this question.
I have included in the modes file, that in the OTRv4-interactive-only mode you don't have to include the query msg or whitespace tag.
Hope that helps
Okay, so from what I understand, you recommend to clear the query tag immediately after use, i.e. once phi is calculated. And this would also mean that you use the query tag in exactly one DAKE. Correct?
AFAICT, this will result in issues when you want to establish a session and the other party has multiple clients active. Let's say Alice sends a query message and remembers the query tag. Multiple clients of Bob's may respond with an Identity message. For each of these responses Alice will perform a DAKE and needs the query tag for this. (This already means query tag is used in more than one DAKE.) Alice cannot delete it immediately after first use, as you cannot know for sure that the first established session is the client Bob is actually using.
edit Alice also cannot know how many responses to expect or in what time-span. You could, of course, restrict the amount of time the query tag is valid.
Now if you would consider that Bob could initiate a session by directly sending an Identity message at that time, how will Alice know whether the Identity message is a response to the query message or an independent initiation? (And consequently, whether or not to include the query tag in the calculation of phi.)
I hope I'm making sense. I'm writing this late in the evening, so I hope I'm not making a stupid mistake/thinko ... (my track record isn't too great :-P)
Ok, just to first clarify: This is actually not related to the modes. Initiating a DAKE with an Identity message can happen on any mode, is only enforced in the Standalone Mode.
AFAICT, this will result in issues when you want to establish a session and the other party has multiple clients active. Let's say Alice sends a query message and remembers the query tag. Multiple clients of Bob's may respond with an Identity message. For each of these responses Alice will perform a DAKE and needs the query tag for this. (This already means query tag is used in more than one DAKE.) Alice cannot delete it immediately after first use, as you cannot know for sure that the first established session is the client Bob is actually using.
edit Alice also cannot know how many responses to expect or in what time-span. You could, of course, restrict the amount of time the query tag is valid
In here you have actually much more problems. Let's say that Alice sends a query message and multiple clients receive it; then Alice sends another query message.. which one you will remember query message 1 or query message 2? which one will you use for the responses?
This is actually easier to solve:
- Alice sends a query message and saves the tag.
- Bob (client 1) receives the query message and saves the tag.
- Bob (client 1) finishes the DAKE with the correct phi. The query tag is deleted.
- Bob (client 2) receives the query message and saves the tag. Sends an identity message
- Alice replies with an Auth-R message, with a phi without the tag (as it is deleted).
- At this point, Bob knowing that query tag on phi is optional, he tries to verify the phi by
a. trying with query tag included
b. trying without query tag included
if both of those fail, then it is a bad verification. But if one is true, the DAKE continues.
Now if you would consider that Bob could initiate a session by directly sending an Identity message at that time, how will Alice know whether the Identity message is a response to the query message or an independent initiation? (And consequently, whether or not to include the query tag in the calculation of phi.)
Yeah. This is a case. The same as if you reply to a past query message, but Alice has already sent another query message (in these two cases, I will say that it should fail).
This is again a problem in the state machine, which we have not fully checked, as it is seen on other issues. :)
But then again, query message or whitespace tag on phi are optional. They don't need to be included.
I hope I'm making sense. I'm writing this late in the evening, so I hope I'm not making a stupid mistake/thinko ... (my track record isn't too great :-P)
No worries. Thanks.
I checked this with Ian. I'll get back with an answer.
Query message and whitespace tag have been removed from phi.