How multiple long-term keys fit into the server's prekey selection

[juniorz]

Original message:

• What happens if you receive two prekey messages with user profiles signed with different long-term keys?

What happens if you locally have two user profiles? This can happen when you locally (in each client/device) have more than one long-term public keys (as far as I know, OTR allows for this, meaning, you can generate new long-term public keys even if you already have one). For each of this long-term public keys, a user profile is created and signed with it (even thought the other parameters on the user profile -except for expiration- remain the same). This is not importing/exporting user profiles but rather having them locally. ADR9 defines this on this terms:

" Alice receives two prekey messages from Bob with different user profiles but the same instance tag (the prekey profiles are signed with the corresponding long-term key stated on the user profiles). This can only validly happen if Bob's client supports two different versions of OTR that use prekey messages or if the long-term key used in each message's User Profile is different.

a. If the versions and the long-term keys used in the messages are the same, and they are compatible with Alice's version, one of the prekey messages must be invalid, but Alice cannot know which. She should not send a message using either prekey message. b. If the prekey message versions are the same and the version is supported by Alice, but the long-term keys are different from each other, Alice should look at whether she trusts the keys. If she trusts both, she may send a message to both. If she trusts only one, she may decide to only send one message or she may send a message to the untrusted key as well. If she trusts neither, she may not send any messages or she may decide to send a message to one or both, despite the risks. c. If the prekey message versions are different and Alice supports both versions, Alice may choose to send a message with both versions or only with one, depending on whether she trusts the long term key or keys associated with them. d. If the prekey message versions are different and Alice supports only one, then she can only send a message with the prekey message she supports. If the long-term key associated with this message is untrusted, she may decide not to send a message. If it is trusted, she may send a message.

[juniorz]

What happens if you locally have two user profiles? This can happen when you locally (in each client/device) have more than one long-term public keys (as far as I know, OTR allows for this, meaning, you can generate new long-term public keys even if you already have one).

The case you describe can be solved by using instance tags only, since instance tags are mandatory in OTR4 and you are talking about having one long-term public key in each client/device. Each client has a different instance tag, and the server already returns one prekey message per instance tag.

Besides this scenario, we have initially thought:

a) Same client concurrently using the same identity with different long-term keys. It does not seem to have any real use case, and also Pidgin does not allow this. We ignored this.

b) The same client wants to replace the current long-term public key by a new one, by either importing or regenerating.

(when we say same client/device we also mean same instance tag)

When (b) happens, clients should also replace the shared prekey, prekey profile and user profile (because of the signature). We could solve this by reuqiring the client to also generate a new instance tag (since it is a completely new device now, with a different prekey profile and user profile - which are per device). In this case, there is no need for the server to worry about this case, because it will always fall into multiple instance tags.

[juniorz]

The part from ADR-009 mentions versions again which is part of #3 .

[juniorz]

I am more interested about what should we do with the previous keys and profiles in case (b). Do we expect them to still be stored (so the associated prekey messages can still be used)?

If that is not the case, it is one more reason to force the instance tag to also be reset (since the previous device, and all its associated data are now useless).

[claucece]

When (b) happens, clients should also replace the shared prekey, prekey profile and user profile (because of the signature).

Mmm... meaning we will require that there exists only one long-term key, user profile, prekey profile per device?

I am more interested about what should we do with the previous keys and profiles in case (b). Do we expect them to still be stored (so the associated prekey messages can still be used)?

I guess that until they expire, they can be used. Unless, we specify that if you generate a new one, you replace the old one. And as far as I know the long-term public keys don't have a defined expiration date...

[juniorz]

Mmm... meaning we will require that there exists only one long-term key, user profile, prekey profile per device?

I was mentioning the consequence of having things signed by the long-term key: if you generate a new long-term public key on pdigin-otr4 you cant keep using things that were signed by the old long-term key.

Can you give me an example of how would you keep using old and new things on the same device?

[claucece]

I was mentioning the consequence of having things signed by the long-term key: if you generate a new long-term public key on pdigin-otr4 you cant keep using things that were signed by the old long-term key.

Yes.

Can you give me an example of how would you keep using old and new things on the same device?

I think what you stated just before. I don't know if this is something clients will allow: generating and having two valid long-term public keys and actually signing with both of them.

[juniorz]

Decision: The prekey server does not need to worry about long-term public keys, because the same identity (alice@xmpp.org) can only have multiple long-term keys if it also has multiple devices/clients. This can be solved by instance tags only, as it is already specified in the prekey server spec.

[juniorz]

One potential problem is what may happen if a client replaces the current long-term key with a new one, and does replace the current instance tag with a new one.

In this case, the server will not be able to differentiate between the prekey messages from the previous long-term key (and previous user profile / prekey profile) and the prekey messages from the new long-term key.

We propose a change to the OTRv4 spec to say something like

When a device/client generates a new long-term public key it MUST discard the previously generated long-term key (and its associated user profile, prekey profile, prekey message private keys) and generate new prekey profile, user profile, AND instance tag.

This will not be done as part of this issue but we need to create a issue on otrv4/otrv4.

[claucece]

What do you think? @olabini

[olabini]

I'm very confused by the last few messages. Of course there can be more than one long-term public key for the same device. Otherwise key rollover can't happen. So there needs to be an association between User Profile, Prekey Profile and Prekey Message, since there can be more than one User Profile with different long term keys.

[juniorz]

Does the OTRv4 explains everything needed for this key rollover (for example, for how long previous long-term keys, previous profiles, previous prekey messages should be stored)?

As we did not have an example for this, we ignored it. But it seems we need this. We will add this then, as initially requested. Please advise about what should be the order of precedence: first group by instance tag, and then by long-term key? Or the other way around?

[claucece]

Does the OTRv4 explains everything needed for this key rollover (for example, for how long previous long-term keys, previous profiles, previous prekey messages should be stored)?

Profiles and prekey messages are valid until they expire and are stored until they are retrieved or replaced (this remains me that a client should warn an user when a stored profile or prekey message is expired and upload new one).

As we did not have an example for this, we ignored it. But it seems we need this.

This is something need for OTRv4-prekey server and it should not be specified over the OTRv4 protocol. In fact, many things there specified are not really needed to ;)

We will add this then, as initially requested. Please advise about what should be the order of precedence: first group by instance tag, and then by long-term key? Or the other way around?

I think this is already putted on the current spec. By instance tag first:

intance tag 0x01 || long_term 1
intance tag 0x01 || long_term 2

intance tag 0x02 || long_term 1

intance tag 0x03 || long_term 1

[juniorz]

Profiles and prekey messages are valid until they expire and are stored until they are retrieved or replaced (this remains me that a client should warn an user when a stored profile or prekey message is expired and upload new one).

We are talking about our own prekeys and profiles. What does retrieving mean in this case?

[claucece]

We are talking about our own prekeys and profiles. What does retrieving mean in this case?

Ah, I thought stored. Then they are valid until they expire. For some moments, decided, by a client, profiles and prekey messages can be a little more valid than what they state (like 1 more hour, or something decided by client) so offline messages used with this prekey message can still be decrypted (think about when a retriever chose a prekey message that was just going to expire and expire in the way of sending offline messages).