[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
_______________________________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
