Decide about message version for prekey messages - Githubissues

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

2 stars 0 forks source link

Decide about message version for prekey messages #3

Closed juniorz closed 6 years ago

juniorz commented 6 years ago

Original message:

Should DAKE prekey messages contain versions? I think no.. but there was not a clear outcome for this discussion: https://github.com/otrv4/otrv4-prekey-server/commit/2b5e99ad0f4d1111b47ae590ac861353ea0d2237#diff-bf23ee0d88b81fe9b683335982d5f63eR77

juniorz commented 6 years ago

The prekey server spec has its own DAKE. We added the fields protocol version and instance tag to each messages.

It is unsure to me the role it plays, since each OTR version is expected to use a different prekey server instance (and potentially a different prekey server protocol).

juniorz commented 6 years ago

Original message by @olabini

This is a bit of weirdness. The user profile contains the supported versions, so it can be a set of "3,4,5". However, what happens if we want to upgrade the user profile format, or the prekey profile format, or the prekey message format? I'm starting to think that both the User Profile and the Prekey Profile needs to have a version specificed as well. And if there are prekey messages for several versions, I think the server needs to return one for each version.

Does that make sense?

juniorz commented 6 years ago

And also from another email:

At 2.12, Ola said:

Assume there are three live OTR versions with prekey servers. 4, 5 and

For Alice to start an offline conversation with Bob, Alice needs to ask three different endpoints to get a valid prekey message. I'm not sure that's a good idea. It feels to me like this is simplifying our part of the protocol at the cost of overall convenience and complexity.

I think we should have one prekey server, and this one has to know how to handle the versions.

juniorz commented 6 years ago

This issue must also state the reasons for having this multiple versions behavior in the ADR-013.

juniorz commented 6 years ago

This also depends on not keeping the following fields of a prekey message unchanged between future versions of OTR:

Protocol version (SHORT)
Message type (BYTE)
Prekey Message Indentifier (INT)
Prekey owner's instance tag (INT)
Prekey owner's User Profile (USER-PROF)
Prekey owner's Prekey Profile (PREKEY-PROF)

(this is the binary "interface" the server expects from a prekey message regardless of version)

otrv4/otrv4#118 is supposed to remove the profiles from the prekey message, but there is still some binary interface that must be explicit in the spec, and also there must be in the spec ways to associate the profiles to the prekey messages (are they gonna be published in a separate service? are they gonna be together with the prekey messages, but in a separate field in the body of the DAKE-3 message)?