otrv4 / otrv4-prekey-server

The Prekey Server specification as needed for the OTRv4 specification. This is a mirror of https://bugs.otr.im/otrv4/otrv4-prekey-server

OTRv4

Disclaimer

This protocol specification is a draft. It's currently under constant revision
by its team members or by its reviewers: Nik Unger or Ian Goldberg.

This is the protocol specification for Off-the-Record Messaging Protocol version 4.

Funding

The work made hare was partially supported by the NlNet Foundation. Find information here.

Licensing and Use

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

The OTR team does not review implementations or specify which ones are compliant are not. Software implementers are free to implement this specification in any way they choose - under limitations of software licenses if using existing software.

otrv4-prekey-server's Issues

Add something about the trust on the long-term public keys

This paragraph keeps coming as something that should be in the prekey server spec:

i. 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.
ii. 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.
iii. 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.
iv. 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.

It is unsure if we should add this to this spec or to the OTRv4 spec, since OTRv4 will not have to bother with multiple versions of prekey messages.

See: 17b0a3a#r28241471

Correctly count on the usageID

Use hex.

Incorporate an extensible Client Profile

As defined on issue 138 of the OTRv4 spec.

Check the attacks and put them on the spec

Original TODO

Check replay, key reused, attacker modifies prekey or format?

• What if the server delivers all the prekey messages to an adversary
• How does forward secrecy is compromised when the prekey server refuses to hand
  out prekey messages?

Add the prekey profile

The prekey profile (otrv4/otrv4#118) was not finished by the first version of the prekey server spec, so it was ignored.

This is about considering the prekey profile when it is done.

Add a "OTRv4-like" fragmentation

Crate a definitions section

Create a definitions section where 'Publisher', 'Retriever', etc are defined.

Define Denial of Service in the context of OTRv4.

Clarify how to validate the received prekey messages

Original message:

• Clarify the checks that the client should do upon receipt of the
  prekey messages. This should be included on the section and not only
  linked to certain part of the OTRv4 spec, as the OTRv4-prekey spec is
  the one that specifically defines this. See:
  17b0a3a#diff-bf23ee0d88b81fe9b683335982d5f63eR559

Add some clarifications

• Add "network" to the definitions section.
• Give better names to usageClientProfile-2, usageClientProfile-3, usageClientProfile
• Give better names to usagePrekeyCompositeIdentity-2, usagePrekeyCompositeIdentity-3, usagePrekeyCompositePHI-2 and usagePrekeyCompositePHI-3
• Add correct links to the "Key Exchange" section.
• Are we duplicating the verification procedures for messages both in the individual message descriptions, and in the "Key Exchange" flow?
• Specify the exact data type of strings.
• Include the MAC on the encoding of the Failure Message.
• The "Network Fragmentation of the Prekey Publication Message" section should be rewritten to make it clear that it's the library/client that fragments the message, not the network.
• Use example.org for the examples.
• When talking about identities for XMPP exemples, the spec sometimes includes the resource, and sometimes not. Which is it?
• Add fragmentation for the Prekey Ensemble Retrieval
• Check the XMPP section.
• Add the server public key to the The XMPP prekey

Clarify the XMPP section

Add something about: The XMPP prekey server public key for the server.

Add a byte counter for Client Profiles

Add a ZKPK of the private keys associated with some public values

Specifically, we would need proofs for:

• ClientProfile public key
• ClientProfile DSA key
• PrekeyProfile shared prekey
• PrekeyMessage y
• PrekeyMessage b

The only flow that needs to be changed is the publication message:

Once the server gets a publication message, it sends back challenge values for each one of the values we need. The client generates the challenges, sends them back, and the server returns success or failure.

We also need to remember that we need to tie the shared secret from the DAKE into the proofs.

We should ratchet the following MACs for these values.

Decide about message version for prekey messages

Original message:

• Should DAKE prekey messages contain versions? I think no.. but there
  was not a clear outcome for this discussion:
  2b5e99a#diff-bf23ee0d88b81fe9b683335982d5f63eR77

How would the prekey server functionality work on a "network" that doesn't have any central infrastructure?

Such as Ricochet.

Add links to sections of OTRv4 spec

Original message:

There are a lot of missing links to the OTRv4 specification that
should state exactly to which section it is referring.

Consider versions for the Prekey server spec

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

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.

Review other encoded messages

Originally, there was 3 DAKE messages part of the protocol which were serialized and base64'd.

There was also 2 messages to differentiate which "authenticated action" you wanted to do in the server (Prekey publication and Storage information) which had messages IDs rather than message types. They would go in the body of a DAKE-3 message.

Finally there was the "Storage Status Message" which were the only other encoded message sent by the server to the client that were encoded. it probably should have had message type rather than message ID.

We need to review how "No Prekey-Messages on Storage Message", "Success Message" and "Failure Message" fit into thiscontext.

Consider sending each submissions of prekey messages/client and prekey profiles as its own its own physical network message

Assign a variable name to each UsageId