[OTR-dev] Questions regarding implementation of the OTR protocol

[Kjell Braden]

[resending the mail to the list since it appears I sent it from the 
wrong address]

Hi Marian,

  I've commented on some of your questions. Keep in mind that I'm no 
expert though.

On 2013-08-06 11:49, Marian Kechlibar wrote:
> 1. There are "keyids" in AKE and "keyids" in Key Management. What is
> their relation? There is a seeming contradiction in descriptions.
> [...]
> Which one holds? Should keyidA be equal to 1 in Reveal Signature, or can
> it be any nonzero random number?

  This might be a mistake in the spec. AFAIK, it is assumed to be 1, but 
the spec doesn't clearly require this (if it isn't, the keyid of the new 
key should reflect this). Just use 1 and be on the safe side, someone 
with more knowledge than me should comment on whether the spec should be 
corrected here.


> 3. The Key Management says:
> "When starting a private conversation with a correspondent"
> [...]
> In principle: when can we consider a private conversation to be
> finished, without breaking compatibility with libotr? Does libotr rely
> on protocols like
> XMPP to consider a conversation finished?

  The spec says:

> MSGSTATE_FINISHED
>     This state indicates that outgoing messages are not delivered at all. This state is entered only when the other party indicates he has terminated his side of the OTR conversation. For example, if Alice and Bob are having an OTR conversation, and Bob instructs his OTR client to end its private session with Alice (for example, by logging out), Alice will be notified of this, and her client will switch to MSGSTATE_FINISHED mode. This prevents Alice from accidentally sending a message to Bob in plaintext. (Consider what happens if Alice was in the middle of typing a private message to Bob when he suddenly logs out, just as Alice hits Enter.)

  So, when Bob logs out or manually wants to end the conversation his 
client sends a message with TLV Type 1. When Alice gets a Type 1 TLV she 
sets her conversation state to MSGSTATE_FINISHED. AFAIK OTR does not 
rely on the network's protocol to signal this (to account for, for 
example, invisible modes).


> 4. The Key Management says:
> "For each correspondent, keep track of: (some keys)"
>
> "Keeping track" means that the keys should be stored? How and for how
> long? Persistently on disk, or transiently in memory? Until restart of
> the underlying messaging application? Or just for the duration of the
> private conversation? The private keys are vulnerable if stored on disk.

  For the duration of the private conversation. You should persistently 
store the fingerprint of the public key exchanged in the Reveal 
Signature and Signature messages, though.


> 5. The Key Management says:
>
> "Upon completing the AKE: If the specified keyid equals..."
> Specified where? By the other party of the AKE, in their Reveal
> Signature / Signature messages? Or in another way?

  Specified by the other party in their Reveal Signature / Signature 
messages.


> 6. Key rotation (in Key Management)
>
> Key Rotation is only performed upon receiving of a data message?
> When the keys are being rotated, the expression "If Alice's public key
> is numerically greater" means the current DH key, right? (And not the
> DSA key used for previous AKE).

  Yes, this is about her newly generated DH g^x.


HTH
-- 
  Kjell