|
|
|
@ -100,6 +100,16 @@ device. If the device observes too many missing key indices in its
|
|
|
|
|
to-device Olm session, however, that may be a sign that the homeserver
|
|
|
|
|
is dropping messages.
|
|
|
|
|
|
|
|
|
|
In this threat model, another thing the homeserver can do is falsely
|
|
|
|
|
claim that the user's cross-signing keys have been reset by another
|
|
|
|
|
device. For the most part, this simply amounts to a denial-of-service
|
|
|
|
|
attack on cross-signing, which is difficult to prevent in
|
|
|
|
|
general. However, it's important to note that if a formerly-verified
|
|
|
|
|
device is told by the server that there's been a key reset, it must
|
|
|
|
|
still hold onto its record of signatures created with the old TSK, and
|
|
|
|
|
re-sign those with the new TSK once it has been able to confirm the
|
|
|
|
|
new MSK as part of becoming re-verified.
|
|
|
|
|
|
|
|
|
|
## Unstable prefix
|
|
|
|
|
|
|
|
|
|
This proposal does not add any new API endpoints, but does add some
|
|
|
|
|