Clarity around when fallback keys count as used

kegan/fallback-keys
Kegan Dougal 7 months ago
parent 7e8a59df1b
commit 9e9fa886a0

@ -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)

Loading…
Cancel
Save