From 9e9fa886a0912c923de387373601f91d4306e65a Mon Sep 17 00:00:00 2001
From: Kegan Dougal <7190048+kegsay@users.noreply.github.com>
Date: Thu, 23 Nov 2023 11:03:51 +0000
Subject: [PATCH] Clarity around when fallback keys count as used

---
 ...4081-claim-fallback-keys-on-network-failure.md | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/proposals/4081-claim-fallback-keys-on-network-failure.md b/proposals/4081-claim-fallback-keys-on-network-failure.md
index 8a9531ebc..e3373364f 100644
--- a/proposals/4081-claim-fallback-keys-on-network-failure.md
+++ b/proposals/4081-claim-fallback-keys-on-network-failure.md
@@ -15,7 +15,7 @@ which can be claimed when OTKs are exhausted. Fallback keys provide weaker secur
 specifically impacting forward secrecy, which protects past sessions against future compromises of keys or passwords.
 The risk is that if the private part of the fallback key is exposed, an attacker may use the key to decrypt earlier
 sessions. This can be mitigated by cycling the fallback key (and hence deleting the private key) once it has been
-used, with some lag time to account for slow networks.
+"used", with some lag time to account for slow networks.
 
 ## Proposal
 
@@ -58,11 +58,20 @@ An example of the new field:
 }
 ```
 
-As a reminder, clients SHOULD rotate their fallback key when they realise it has been used, with some lag time
+As a reminder, clients SHOULD rotate their fallback key when they realise it has been "used", with some lag time
 to account for federation. As per MSC2732, 1 hour is recommended. When clients change their fallback key, a new
 `m.device_list_update` EDU MUST be sent.
 
-This proposal has no client-side changes.
+The definition of when a fallback key is "used" also needs to change. Previously, a key is "used"
+_if it is claimed by another device_. When this happens, the client is told this via `/sync`, either by reducing
+the one-time key count by 1, or by removing the algorithm from the `device_unused_fallback_key_types`. This proposal
+makes it impossible to know if the fallback key has been claimed by another device, as it is sent eagerly over
+federation. Therefore, this changes the fallback key semantics to be "when the device receives and successfully
+decrypts an initial pre-key to-device event which uses that key". As per the specification, this is identified as
+`type: 0` messages. This will require client-side changes to change when new fallback keys get uploaded.
+
+Due to this change, it is recommended that the fallback key is _also cycled periodically_, e.g once per week.
+This ensures that any sessions the client is unaware of will eventually expire.
 
 ## Comparisons with X3DH (Signal)