MSC4225: Specification of an order in which one-time-keys should be issued #4225
Conversation
richvdh
changed the title
turt2live
added
e2e
proposal
richvdh
removed
the
needs-implementation
richvdh
changed the title
|
@mscbot fcp merge |
|
Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people: Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
mscbot
added
proposed-final-comment-period
| possible for a to-device message to be delayed so long that the recipient has | ||
| discarded the private part of the one-time key. It is, however, a significant | ||
| improvement. A possible future solution is for clients that expect to be used | ||
| in conditions of poor connectivity to keep old OTKs for longer. |
There was a problem hiding this comment.
AIUI there's almost always going to be situations where the client receives a to-device message using an OTK it no longer has. Is there any mechanism to handle this situation, e.g. a reply asking the sender to retry?
There was a problem hiding this comment.
Not at the moment. We've had thoughts about that sort of thing. TBH though, I think it's pretty unlikely to happen once we fix the ordering problem, unless the sender literally goes offline for a year just after claiming the OTK.
| 2. [MSC4162](https://github.com/matrix-org/matrix-spec-proposals/pull/4162) | ||
| proposes a mechanism by which a client can inform the server that it is | ||
| discarding certain OTKs, so that the server can also remove the public | ||
| keys. This seems a heavier-weight solution to the problem. |
There was a problem hiding this comment.
Sort of wondering whether clients should replace all OTKs on the server at once, rather than appending new ones to the list? That way whenever the client replaces all the OTKs its easier to then say "we can discard the previous batch of OTK private keys in N days".
Just an ideal non-blocking thought.
There was a problem hiding this comment.
erm... not really following how that would work/help.
There was a problem hiding this comment.
This is the kind of idea I was toying with in my discussion: replacing the whole lot every time would have the effect of removing any keys that the device had deleted from the server. It's probably a similar conclusion to that conversation.
| This presents a problem: there is a limit to the number of private one-time | ||
| keys that a client can retain. Over time, as keys are repeatedly claimed, | ||
| replaced with newly-generated keys, but not actually used, the client must | ||
| start to discard older keys. |
There was a problem hiding this comment.
OOI how long do clients typically retain these keys?
There was a problem hiding this comment.
libolm kept 100. Vodozemac keeps 5000.
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
mscbot
added
final-comment-period
|
Let the record show that i was having a slight wobble over some dim memory of whether there was some impact on deniability by being able to predict the order that OTKs are consumed. Looks like there isn't, but for posterity, the raw discussion was:
|
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
mscbot
added
finished-final-comment-period
and removed
disposition-merge
final-comment-period
|
Spec PR: matrix-org/matrix-spec#2029 |
turt2live
added
spec-pr-in-review
richvdh
added
merged
|
merged! |
As per matrix-org/matrix-spec-proposals#4225, fetch the oldest OTKs first.
Rendered
Implementation: element-hq/synapse#17903, element-hq/synapse#17934
FCP tickyboxes