archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

typos

Browse Source
rav/proposal/otks_in_upload_order
Richard van der Hoff 1 year ago
parent c181b1c5f4
commit 06300cf792
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File

13
proposals/4225-one-time-key-ordering.md
Unescape Escape View File

@ -29,13 +29,14 @@ This proposal is not a complete solution to the problem of premature discarding
of one-time keys: even if the server issues a recent one-time key, it is still of one-time keys: even if the server issues a recent one-time key, it is still
possible for a to-device message to be delayed so long that the recipient has 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 discarded the private part of the one-time key. It is, however, a significant
improvement. A possible solution is for clients that expect to be used in improvement. A possible future solution is for clients that expect to be used
conditions of poor connectivity to keep old OTKs for longer. in conditions of poor connectivity to keep old OTKs for longer.
There are other ways in which the server and client can get out of sync with There are other ways in which the server and client can get out of sync with
respect to one-time keys, including by a [database respect to one-time keys, including by a [database
rollback](https://github.com/element-hq/element-meta/issues/2155), or rollback](https://github.com/element-hq/element-meta/issues/2155), or
implementation defects. implementation defects. It is anticipated that other solutions will be found
for those situations.
## Alternatives ## Alternatives
@ -53,7 +54,7 @@ implementation defects.
2. [MSC4162](https://github.com/matrix-org/matrix-spec-proposals/pull/4162) 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 proposes a mechanism by which a client can inform the server that it is
discarding certiain OTKs, so that the server can also remove the public discarding certain OTKs, so that the server can also remove the public
keys. This seems a heavier-weight solution to the problem. keys. This seems a heavier-weight solution to the problem.
3. A more invasive alternative would be to design an encryption stack which 3. A more invasive alternative would be to design an encryption stack which
@ -82,7 +83,7 @@ None.
## Appendix: detailed explanation of the failure mode ## Appendix: detailed explanation of the failure mode
### Backgroynd ### Background
End-to-end encryption in Matrix relies on individual devices sharing End-to-end encryption in Matrix relies on individual devices sharing
[Megolm](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md) [Megolm](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md)
@ -114,6 +115,8 @@ See [One-time and fallback
keys](https://spec.matrix.org/v1.12/client-server-api/#one-time-and-fallback-keys) keys](https://spec.matrix.org/v1.12/client-server-api/#one-time-and-fallback-keys)
which specifies much of this behaviour. which specifies much of this behaviour.
### Problem
Clearly, a device must retain the private part of each one-time key until that Clearly, a device must retain the private part of each one-time key until that
key is used to establish an Olm session. However, for a number of reasons, key is used to establish an Olm session. However, for a number of reasons,
ranging from network errors to malicious activity, it is possible for a claimed ranging from network errors to malicious activity, it is possible for a claimed

Write Preview
Loading…
Cancel
Save