[OTR-dev] mpOTR: Error conditions

[Abel Luck]

Hi,

In an effort to move things forward, I present an analysis of possible
error states during startup and shutdown that need to be handled by
protocol implementations.

References to the mpOTR paper [1] will appear in parenthesis in the
format of (pg num, subheading, par num).

The focus for this discussion is how to handle the errors, and what
should be displayed to the user. Remember each error happens from the
perspective of a single participant.

I don't examine the communications phase, only the setup and shutdown
phases. Anyone have errors that can occur during the communications
phase?

Intitiate() Errors
---------------

1. Failed signature-key exchange consensus
   (8, Multi-party sig key exchange, 1)

 Task: Participants run Alg. 4 and compute hash of association table
 then send to others

 When: During Initiate(Pi) after globally unique session id is
 created, before group key agreement

 Expected Condition: Hashes Alice receives are consistent AND match
 her own hash

 Error Condition: Alice receives inconsistent hashes from other
 participants OR Alice's hash does not match received hashes

 Consequence: Signature-key exchange failed. Pi is possibly
 inconsistent or a MITM occurred. Cannot continue Initiate()

2. Group key agreement fails
   (8, 4.2.2, 1)

 Task: Establish group encryption key, gk

 When: During Initiate(Pi) after signature-key consensus

 Expected Condition: GKE fails (actual failure depends on algorithm)

 Consequence: Cannot continue Initiate()

3. Attest() consensus fails
   (7, 4.2, 5)

 Task: Receive hash of chat parameters from all participants and
 verify consistency

 When: During Intitiate() as part of Attest()

 Expected Condition: Hashes Alice receives are consistent AND match
 her own hash

 Error Condition: Alice receives inconsistent hashes from other
 participants OR Alice's hash does not match received hashes

 Consequences: Session initialization failed

Discussion
----------

 Since 1, 2, and 3 are essentially the same ("Initiate() failed"), the
 UI can inform the user they were unable to start or join the chat.

 However, we presumably want to try and recover, so something must
 happen on the protocol level. This should be worked into the mpOTR
 state machine, possibly in a later version of mpOTR.

 How should we handle a failed Inititate()? How can we reboot the chat
 session for all participants?

Shutdown() Errors
-----------------

 Assuming the protocol will use the "crude" Shutdown() algorithm
 described in the paper, there are the following error conditions.

4. Session transcript consensus fails due to inconsistency (9, 4.4, 3)

 Task: Collect transcript digests from participants and verify
 consistency

 When: During Shutdown()

 Expected Condition: Session transcript digests are consistent for all
 participants, including Alice

 Error Condition: Alice receives inconsistent digest from other
 participants OR Alice's digest does not match received digests.

 Consequence: Inconsistent transcript state, Shutdown() fails

5. Session transcript consensus fails due to missing digests

 Task: Collect transcript digests from participants and verify
 consistency

 When: During Shutdown()

 Expected Condition: Received session transcript digests are
 consistent for all participants, including Alice

 Error Condition: After some timeout, transcript digests from all
 participants do not arrive.

 Consequence: Transcript consensus cannot be reached, Shutdown() fails

Discussion
----------

 Errors in Shutdown() cannot simply be aborted from, as the Shutdown()
 algorithm is required to ensure the deniability properties of mpOTR.
 However, as noted in the paper in the last paragraph before the
 conclusion,

     The protocol is deniable even without publishing
     the ephemeral signing keys. Therefore, we gladly trade the
     deniability benefits gained by allowing malleability for en-
     suring that the adversary will not be able to impersonate X.
     [...]
     However, if parties do publish their ephemeral signing
     keys then the existing transcripts can be tweaked.

 In other words, if the Shutdown() fails the forgeability property is
 not achieved, but malleability property is.

 Shutdown() can fail for a variety of reasons: dishonest users,
 network jitter, users who closed the chat before Shutdown() could
 complete, etc.

 A best attempt should be made to complete the Shutdown() algorithm to
 achieve all the deniability properties.

 If Shutdown() fails due to error 4 or 5, AuthSend("end") should stil
 be executed, but broadcast of ephemeral signing keys should not
 occur.


[1]: http://www.cypherpunks.ca/~iang/pubs/mpotr.pdf