Figure out how to solve version rollback completely

[tcz001]

The OTRv2 and v3 is doing version according to the query message ?OTRv3?, we should consider downgrade attack if MITM has capability to change this header.

Or, once we have otr4, we should also consider the deprecation of otr3/otr2 when we have otr5.

A version rollback may require key management for all versions, so that it can be able to handle different implementations AKE.

According to the TLS spec, we may also need statement rules like, implementation SHOULD/SHOULDNOT/MUST/MUSTNOT/CAN/SUGGESTED do something.

[olabini]

I'm very confused about this description. I have no idea what you're saying actually. OTR has two ways of starting a conversation - one of them is an actual start - this happens when someone forces encryption or presses the button to start encryption. In the other case, the whitespace tag will advertise versions available.

In order to stop version rollback from being possible, the handshake needs to contain authenticated information about what versions were offered - and that becomes harder because both sides do not always offer versions.

[tcz001]

that's why I say avoid MITM, OTR4 probably should be the first version that contains authenticated version agreement.

Besides, the rollback is not the only problem, for compatibility, we need to consider the case a fallback happens and mention how to handle older versions. for example, using different keys for different versions.

[olabini]

Right, but your description didn't say any of that.

And yes, we need the other stuff too. But that's not for this issue. Open a different issue for that.

[tcz001]

Why I didn't say that exactly is because authentation might be something too strong, and may break denialbility. We need a way to avoid rollback, but carefully keep the rest properties.

[olabini]

I don't understand this comment at all.

[tcz001]

I mean authentation needs some extra identity or key, and it may break denialbility if not designed carefully.

[olabini]

No of course not. We need to stop version rollback from happening. That just means that version information needs to be baked in somewhere in the AKE.

[tcz001]

hm... in this case, the old query message response should be moved into AKE then.

[tcz001]

Hey,

We did an investigation to how the version can be authenticated in DAKE, it seems that we can include "OTRv4" in the message when doing NIZKP-Auth.

We can use ("R"; g^r; Auth(g^R, R, {g^I , g^R, g^i}, "OTRv4 || 0 || I || R"))

This would bind the AKE to the version negotiation, which is a change from previous versions.

Fan & Chelsea

[tcz001]

Another option would be to use a NIZKP signature with the version separate from the AKE.

[tcz001]

As @juniorz mentioned this morning, we probably don't need to change the version negotiation if we have an assumption, that there will be something like a policy for version restriction. Otherwise if we do a authenticated version negotiation, it means we are actually setting up a integrity channel before we do AKE.

I'm adding some rollback scenarios here to be more specific:

• Alice and Bob are initiating a conversation first time.
• Alice and Bob have already agree on the version and done the AKE.
• Alice and Bob have already agree on the version, haven't done the AKE. removed because every AKE/data message should contain same version number inside

Both cases can have a MITM to forge request/response of a QueryMessage, before and after AKE, to restart the conversation and rollback the version.

So options we can think about:

1. using policy to avoid a version rollback, controlled by user/client preference
2. using a trustful channel before AKE to avoid the version rollback
3. using AKE to authenticate the version negotiation

[rosatolen]

To be clear, our OTRv4 version negotiation should be backwards compatible with the Query Message and Whitespace tag in OTRv3 so that if Alice only supports versions 3, but Bob supports version 3 and 4, they will be able to talk to each other with OTRv3.

[rosatolen]

Problem: Currently, there is no provision in OTR to stop version rollback when both participants support versions x and y where y > x.

I have two proposals to address this. The first is an interactive version negotiation that is compatible with OTR3. The second is a non-interactive version negotiation that includes a pre-key, which is not compatible with OTR3. Both flows trigger a protocol error when tampering of the first version advertisement is detected and use the Duel Receiver Encryption (DRE) and NIZKPK (Auth) in "Improved Techniques for Implementing Strongly Deniable Authenticated Key Exchanges".

Interactive:

1. Alice sends ?OTRv45? to Bob in a Query Message or a Whitespace tag
2. Bob uses Duel Receiver Encryption with Alice and Bob's Public Keys over the following information: Alice's ID, Alice's version message ?OTRv45?, Bob's ID, Bob's version advertisement (in this case ?OTRv45?). Bob also computes an Auth over the DRE message. Bob sends the encrypted message and the auth to Alice. Bob does not send information to begin the AKE here becaues he cannot be sure that Alice advertised ?OTRv45?.
3. Alice verifies the auth and decrypts the information. In this way, she is able to identify whether her Query Message or Whitespace tag were tampered with. If the message is invalid, there is a protocol error. If not, she learns what versions Bob's policy supports and is able to start the version 5 DAKE with him in the next message.

Non-interactive:

1. Alice places her half of the shared secret g^a and which versions she is willing to use on an intermediary server ?OTRv45?.
2. Bob retreives the prekey and the versions Alice wishes to use. He computes g^b as his half of the shared secret. He computes a DRE message over the information: Alice's ID, g^a, ?OTRv45?, Bob's ID, Bob's version advertisement: ?OTRv45?, and g^b. He also computes Auth over the DRE message, and sends both to Alice.
3. Alice validates the auth and decrypts the information. If the message is invalid, there is a protocol error, else Alice continues with version 5.

The non-interactive version doesn't describe what "continuing with version 5" means, because there is no concrete example of version 5, which may even have a different DAKE, so what g^a represents in that case is unclear.

Suggestions and feedback are appreciated.

[rosatolen]

Also the proposals above do not protect against downgrade attacks from version 4 to version 3 when both sides support versions 4 and 3, since version 3 has no rollback protection.

[olabini]

I'm a bit confused by these descriptions. It seems the interactive flow requires a completely new flow before the DAKE? I don't understand how it fits in with the DAKE right now at all.

The non-interactive I'm even more confused by actually.

[rosatolen]

The negotiation was separated to allow for key exchange changes into the future. If we embed the negotiation into an AKE specific to version four, how does this address rollback issues for future versions of OTR?

Also Fan and Chelsea have made a suggestion above for adding the version to what is encrypted in the DRE specific to the key exchange for version 4.

I'm not sure what else we can try.

[rosatolen]

I don't understand how it fits in with the DAKE right now at all.

After Alice verifies the version negotiation in step 3, she will send the first part of Spawn in her next message to Bob: "A", g^a.

[rosatolen]

Maybe we should not care about version negotiation for future versions of OTR that use a different DAKE?

[olabini]

This makes me really confused. We can't have a separate version negotiation. What's important is that each DAKE from now on contains version information such that we can detect rollback attempts. They don't have to be the same.

[olabini]

Of course we should care about future versions. Otherwise what's the point of adding version negotiation?