Alice requests an interactive conversation with Bob about otrv4

[juniorz]

I'm not sure I understand the flaw you are talking about.

Talking about the problem of establishing a secure channel on OTRv3 over XMPP: even though you are able to have some information about peer availability from the network, there's nothing you can do about it simply because the OTRv3 doesn't provide a capability that can be used when the other peer is offline.

You can use a network/messaging specific capability to develop a timeout - for example, by requesting a message delivery receipt (XEP-0184) for the first AKE message sent and timing out if the receipt doesn't arrive in a reasonable time - but there's nothing else you can do in OTRv3 if your current policy includes REQUIRE_ENCRYPTION besides turning it off for the peer and proceed by sending unencrypted offline messages (until it goes back online).

Providing a non-interactive alternative gives one alternative to the problem, but deciding when to use it should be part of the messaging client, who has enough information to make a decision.

[tcz001]

1. Alice first confirm with a server (xmpp jabber for example), that Bob is online
2. Alice send Query Message for OTR version
3. Bob reply a OTRv4
4. Bob initiate the RSDAKE, choose an ephemeral secret i, and send {"I"; g^i} to Alice
5. Alice receives g^i, and choose an ephemeral secret r, computes k=g^(i*r), and send {"R"; g^r; Auth(R)} to Bob, securely erase r.
6. Bob verifies Auth from Alice, send {Auth(I)} to Bob, and reveal g^r, computes k=g^(r*i), securely erase i
7. Alice verifies Auth from Bob
8. They now have a shared and authenticated secret key, k

[olabini]

"Alice first confirm with a server (xmpp jabber for example), that Bob is online" - you can't have this as part of the flow. Most IM services just doesn't work like that.

The description should also be done in terms of the primitives we are using, not using exponentation and multiplication.

Also, this doesn't actually describe the AKE for OTR - we will likely need other things.

[iapazmino]

Can the OTR layer ask the underlying layer about Bob's presence?
This is to avoid setting timeouts to the start of an interactive conversation in case Bob is offline.

[olabini]

No. We can't assume we are using a transport that has presence information at all.

[olabini]

And even for XMPP that information can go stale or be incorrect, or the person can be invisible.

[tcz001]

sounds like a timeout is still necessary?

[juniorz]

Specifying a timeout seems to be out of scope of the protocol. For me, the protocol provides 2 capabilities in regard to DAKE: an interactive key-exchange and a non-interactive key exchange.

The client should be who decides when to use each capability: a client may decide to always use the non-interactive version (for convenience) or always use the interactive version (for stronger security properties).

In order to be able to specify values for timeout, a protocol would need to know what is an acceptable RTT for the messaging protocol, or if the message protocol provides any timeout capability for messages.

It seems to me the only capability from the messaging protocol we expect is the ability to send and receive messages in order, as stated by OTRv3 network model.

[tcz001]

In that case, we will leave the spec without a clear clarification of "online" and "offline" state, which I'm not sure if it's fine for implementers.

[juniorz]

Without deciding on which DAKE to use, the output of this story is just talking about the interactive key-exchange in general terms (because all the details will depend on which DAKE we are using).

The steps will be:

1. Alice starts a interactive key-exchange with Bob by generating and sending a ψ1 message (which is DAKE specific). Alice in this setting is considered to be the initiator (I).
2. Bob receives ψ1, verifies it, then generates and sends ψ2. Bob is considered to be the responder (R).
3. Alice and Bob keep exchanging ψ messages until the key-exchange finishes. After the interactive key-exchange succeeds, they will have a shared secret.
4. Both sides derive session keys from this shared secret.
5. They exchange encrypted messages using the session keys.
6. They ratchet the session keys.

I'm unsure if this is the expected output of this story.

[iapazmino]

Depends on #15

[juniorz]

@tcz001 there is no "online" and "offline" state from the protocol perspective: they are a client state. The client using the protocol should be able to determine this state (if available) in a network/messaging-specific way and, based on this state, choose which feature of the protocol it wants to use.

[tcz001]

but wasn't this uncertainty we felt a flaw of otr3?

[juniorz]

The issue seems to be more because of REQUIRE_ENCRYPTION and the lack of a non-interactive key-exchange rather than lack of online/offline state. I've added #25 to address consequences of OTRv4 to the policies.

[tcz001]

Yeah, that's actually what I mean, thanks.

[claucece]

Assuming SPAWN as the DAKE, it becomes:

(Here the initiator -I- will be referred as Alice and Receiver -R- as Bob).

This should be specified in another section, to avoid duplication with #18:
TODO: move to another section.

• G: group to be used for all key exchanges.
• q: the (prime) order of the group.
• p: a safe prime generated with a Sophie Germain prime q.
• g1 and g2: the distinct Cramer-Shoup generators for the group, suitable for Diffie-Hellman key exchanges and the Cramer-Shoup cryptosystem.

Alice long-term Cramer-Shoup key-pair is SKa = (x1A, x2A, y1A, y2A, zA) and PKa = (cA, dA, hA).
Bob long-term Cramer-Shoup key-pair is SKb = (x1B, x2B, y1B, y2B, zB) and PKb = (cB, dB, hB).

Alice:

1. Generates an ephemeral Diffie-Hellman private key i and public key g1^i, with parameters (p, q, g1), uniformly at random.
2. Sends ψ1 = ("I"; g1^i) to Bob.

Bob:

1. Generates an ephemeral Diffie-Hellman private key r and public key g1^r, with parameters (p, q, g1).
2. Computes γ = DREnc(PKb, PKa, “I” ∥ “R” ∥ g1^i ∥ g1^r). The identifiers for the parties ("I" and "R") may be cryptographic hashes of usernames or other identifiers provided by the higher-level protocol.
3. Computes σ = Auth(hA, zB, {hA , hB, g1^i }, “I” ∥ “R” ∥ g1^i ∥ γ).
4. Computes k = (g1^i ) * r and securely erases r. (And derive session keys from the shared secret k at this point, if she wants to embed an encrypted data message on ψ2).
5. Sends ψ2 = (“R”, γ, σ) to Alice. At this moment, k can be used to encrypt an initial message to Alice (and save one round-trip).

Alice:

1. Verifies the proof σ.
2. Decrypts γ using SKa. TODO: dec verification can fail at this point.
3. Verifies the following properties of the decrypted message:
   • The message is of the correct form (e.g., the fields are of the expected length);
   • Alice's identifier is the first one listed;
   • Bob's identifier is the second one listed, and it matches the identifier transmitted outside of the ciphertext; and
   • g1^i is a pre-key that Alice previously sent and remains unused.
4. Computes k = (g1^r) * iand securely erases i. If an initial message was attached, Alice can decrypt the message using k.

[juniorz]

Needs to be moved to the spec. On hold until we solve the hard questions.

[tcz001]

can be closed after 06a5998 and c991b01