From 6d1c02922f4c45682d9a492a1c8849e2725c6fca Mon Sep 17 00:00:00 2001 From: Kegan Dougal <7190048+kegsay@users.noreply.github.com> Date: Tue, 23 Apr 2024 18:37:40 +0100 Subject: [PATCH] Update 3967-device-signing-upload-uia.md --- proposals/3967-device-signing-upload-uia.md | 31 +++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/proposals/3967-device-signing-upload-uia.md b/proposals/3967-device-signing-upload-uia.md index 08853b50..0aba7cff 100644 --- a/proposals/3967-device-signing-upload-uia.md +++ b/proposals/3967-device-signing-upload-uia.md @@ -61,6 +61,37 @@ However, this degradation needs to be weighed against the typical real world situation where a Homeserver will be applying a grace period and so allow a malicious actor to bypass UIA for a period of time after each authentication. +### Existing users without E2EE keys + +Existing user accounts who do not already have cross-signing keys set up will +now be able to upload keys without UIA. If such a user has their access token +compromised, an attacker will be able to upload a `master_key`, `self_signing_key` +and `user_signing_key`. This is a similar threat model to a malicious server admin +replacing these keys in the homeserver database. + +This does not mean: + - the attacker can "take over the account". Device login/logout endpoints are + still protected via UIA. + - the device will appear as verified. This requires out-of-band verification e.g + emoji comparison, which will correctly detect the MITM'd key. + +The main usability issue around this endpoint is requiring UIA, so it is critical +that we only require UIA when absolutely necessary for the security of the account. +In practice, this means requiring UIA when keys are _replaced_. There have been +suggestions to reintroduce a grace period (e.g after initial device login) or just +mandate it entirely for these old existing accounts. This would negatively impact +usability because: + - it introduces temporal variability which becomes difficult to debug. + - it introduces configuration variability which becomes difficult to debug. It's not + clear what the grace period should actually be. Anything less than 1 hour risks + catching initial x-signing requests from users who are on particularly awful networks. + However, even increasing this to 1 hour poses the risk that we incorrectly catch the + initial upload (e.g the client logs in on a bad GSM connection, then give up waiting + for it to login and close the app, only reopening it the next day). This becomes + difficult to debug in bug reports, as they just report HTTP 401s and it is unknown what + the HS configuration is for the time delay. This is seen already due to the use (or non-use) + of `ui_auth.session_timeout`. + ## Unstable prefix Not applicable as client behaviour need not change.