From 7d56dc0b5dfed2da7b905c814a58fd789d5d2e57 Mon Sep 17 00:00:00 2001 From: Faye Duxovni Date: Fri, 30 Sep 2022 17:27:45 -0400 Subject: [PATCH] note about how to handle key resets --- proposals/3834-tofu.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/proposals/3834-tofu.md b/proposals/3834-tofu.md index 15315bf6d..08c3031bf 100644 --- a/proposals/3834-tofu.md +++ b/proposals/3834-tofu.md @@ -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