One-time-key upload/claim is racy

[turt2live]

• Alice tries to upload one-time-key, but doesn't get response
• Bob claims the key
• Alice uploads the key again
• Charlie claims the key

Only one of Bob or Charlie can use the key to talk to Alice.

[richvdh]

I think the only real solution to this is for the server to remember it has recently seen and handed out a given OTK, and not hand it out a second time even if it gets uploaded again. As such, I'm not entirely convinced it is a spec issue so much as a server-side impl issue (though certainly the spec could make the necessary behaviour explicit).

[richvdh]

Another option would be:

• Oblige clients to give each OTK they generate a numeric ID, which must increase monotonically.
• The server hands out OTKs in order of increasing ID, and remembers the ID of the last-issued OTK.
• If the server sees a client uploading an OTK whose ID is less-than/equal-to that of the the last-issued OTK, it ignores the new upload but returns a 200.

The advantage is that the server wouldn't have to keep a record of issued OTKs. The disadvantage is that it means API changes, and changes client-side as well as server-side.

[kegsay]

it ignores the new upload but returns a 200.

This superficially feels like it could hide bugs (e.g if a client uploads a different key with a lower numeric ID, there's no evidence it wasn't stored). But other than that, I like it.

[richvdh]

This superficially feels like it could hide bugs (e.g if a client uploads a different key with a lower numeric ID, there's no evidence it wasn't stored). But other than that, I like it.

As long as the server also checks that there isn't already a different key with the same alphanumeric ID, I don't think this would hide any more bugs than are already hidden?