Giters

otrv4 / otrv4

Off-the-Record Messaging Protocol version 4. -This is a draft- This repository is a mirror of http://bugs.otr.im/otrv4/otrv4

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fragmentation requirements (discarding) mistake and request

cobratbq opened this issue · comments

commented

The specification says the following regarding fragmentation:

Discard the message and optionally pass a warning to the participant if:
  * The recipient's own instance tag does not match the listed receiver instance tag.
  * The listed receiver's instance tag is not zero.

The second requirement "The listed receiver's instance tag is not zero." should probably say ... is zero, right? (As in, you expect to be able to verify that the fragment is indeed intended for this receiver.)

If so, could we make an exception to allow zero receiver tag for the (Interactive DAKE) Identity Message? The Identity message becomes quite large due to the ClientProfile being embedded in this message. (IIRC around 2062 bytes.) That is quite significant. It would surpass the IRC bound four times. (There's probably a similar message for the non-interactive DAKE, but I haven't looked into that yet.)

NOTE: The identity message, like the OTRv3 DHCommit message, may contain the zero receiver tag due to it being the first encoded message being transmitted. The receiver instance tag is not yet announced.

commented

This can only happen in the case of the Identity message.

The second requirement "The listed receiver's instance tag is not zero." should probably say ... is zero, right? (As in, you expect to be able to verify that the fragment is indeed intended for this receiver.)

This can only happen in the case of the identity message. It should not happen in the case of the Prekey message. Why will it happen in any other case?

If so, could we make an exception to allow zero receiver tag for the (Interactive DAKE) Identity Message? The Identity message becomes quite large due to the ClientProfile being embedded in this message. (IIRC around 2062 bytes.) That is quite significant. It would surpass the IRC bound four times. (There's probably a similar message for the non-interactive DAKE, but I haven't looked into that yet.)

Well, actually the identity message is one of the smallest messages in both DAKEs. But sure. :)

The two statements you refer to:

Discard the message and optionally pass a warning to the participant if:
  * The recipient's own instance tag does not match the listed receiver instance tag.
  * The listed receiver's instance tag is not zero.

are taken from the OTRv3 spec, so we will have to check if there was the consideration of fragmenting the OTRv3 DHCommit message.

commented

In OTRv3 spec:

If the recipient's own instance tag does not match the listed receiver instance tag, and the listed receiver instance tag is not zero, the recipient should discard the message and optionally pass along a warning for the user.

In OTRv3 spec, it requires that both conditions hold to discard: receiverInstanceTag != myInstanceTag && receiverInstanceTag != 0. Are the two bullet points above supposed to be a conjunction? (Because I read it as independent conditions, so either bulletpoint 1 or bulletpoint2.) If so, maybe make explicit in the line "Discard the message and optionally ..."?

You're right that the Identity Message is one of the smaller messages, but it's the one that may have "receiver instance tag" equal to zero. I think the confusion was caused by the bulletpoint-list. I read it as a list of independent conditions.

commented

Are the two bullet points above supposed to be a conjunction?

Yes. I'll put an 'and' so people don't get confused. Thanks.