[OTR-users] mpOTR: replay attacks from insiders

[Matthew Van Gundy]

On 8/29/10 3:04 PM, Christoph A. wrote:
> On 08/29/2010 10:46 PM, Gregory Maxwell wrote:
>>> If I understand AuthSend() - defined in algorithm 5 - correctly, it does
>>> not contain any counter that would prevent such a replay attack.
>>> Is that correct or did I miss something that prevents already such an
>>> attack? (beside the consensus check in shutdown())

Your understanding of AuthSend() is correct.  Due to space and time 
limitations, we left preventing consensus violations throughout the 
conversation to future work (which is now under submission).

> A replay-proof signature would prevent the attack from
> happening/succeeding in the first place.
> Alice would refuse to accept the signature in line 5.
> The consensus check detects it after the fact at the end of the chat
> session, therefore I think I would prefer the first solution.	
>
> I would be surprised that such a replay attack is possible (which is not
> confirmed yet) because including a counter in sign() would defeat the
> attack.

We did not opt for either of these partial solutions because neither is 
sufficient to ensure our notion of consensus.  Take, for example, the 
setting of a duplicitous adversary:

Bob's view:
1 Charlie: Bob, please answer these questions.
2 Charlie Do you like ice [y/n]?
3 Bob: y
4 Charlie: Do you like hockey [y/n]?
5 Bob: y

Alice's view:
1 Charlie: Bob, please answer these questions.
2 Charlie Do you like ice [y/n]?
3 Bob: y
4 Charlie: Do you like soccer [y/n]?
5 Bob: y

Charlie has now convinced Alice that Bob likes soccer without forging a 
message from Bob.

> To be honest I also have a question regarding the consensus that is
> somehow connected to the replay scenario:
>
> Alice view:
>
> 1 Alice: Does it rain?
> 2 Bob: yes
> 3 Alice: really?
> 4 Bob: no
>
> Bob's view of the same chat room:
>
> 1 Alice: Does it rain?
> 2 Bob: no
> 3 Alice: really?
> 4 Bob: yes
>
> Charlie's view
>
> 1 Alice: Does it rain?
> 2 Alice: really?
> 3 Bob: no
> 4 Bob: yes
>
> Consensus checklist:
>   - same set of participants ->  ok
>   - same sid ->  ok
>   - same set of messages ->  ok
>   - each message origin ->  ok
>
> consensus reached?
>
>  From chapter 4.4:
> "To ensure that out-of-order message delivery does not affect this
> digest, the messages are taken in lexical order. Note however, that
> should messages include a suitable order fingerprint, the lexical order
> coincides with delivery and creation order, hence our ordering is not
> restrictive."
>
> The remaining question is: Which order fingerprint is chosen?

As Berkant mentioned, we left this open to discussion.  In the protocol 
under submission, we have defined ordering as potential causality over 
the messages at the mpOTR API level (i.e. provided to AuthSend() or 
returned from AuthReceive()) at any honest participant.  This also 
addresses the ordering issue you raised above.  a -> b = a potentially 
caused b (or a sent or delivered by b's author before b was sent). 
Therefore, we have the following causal precedence relation:
Alice: Does it rain? -> Bob: no
Bob: no -> Alice: really?
Alice: really? -> Bob: yes

Honest participants deliver messages in causal order, ensuring that 
Alice, Bob, and Charlie have the same view of all messages that could 
have potentially influenced one another.  They will all arrive at the 
following transcript:
1 Alice: Does it rain?
2 Bob: no
3 Alice: really?
4 Bob: yes

This also avoids the need for a replay-proof signature.  Incidently, is 
there a standard notion for replay-proof signatures that you are 
referring to?  And, do they meet our criteria for transferability among 
conversation participants?

Cheers,
Matt