From d5a2a284c534dc34c819033d0c048f65554fdd7b Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Mon, 15 Feb 2021 12:42:50 +0000 Subject: [PATCH] Note clients should try to prevent impersonation attacks during knocking --- proposals/2403-knock.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/proposals/2403-knock.md b/proposals/2403-knock.md index fdba1e36..c30516c8 100644 --- a/proposals/2403-knock.md +++ b/proposals/2403-knock.md @@ -532,6 +532,9 @@ After a knock is received in a room, it is expected to be displayed in the timeline, similar to other membership changes. Clients can optionally add a way for users of a room to review all current knocks. +Please also note the recommendations for clients in the "Security considerations" +section below. + # Security considerations Clients must take care when implementing this feature in order to prevent simple abuse vectors that can be accomplished by individual users. For @@ -544,7 +547,15 @@ essentially allow outsiders to send messages into the room. It is still theoretically possible for a homeserver admin to create many users with different user IDs or display names, all spelling out an abusive -message, and then having each of them knock in order. +message, and then having each of them knock in order. + +Clients should also do their best to prevent impersonation attacks. Similar to +joins, users can set any displayname or avatar URL they'd like when knocking on +a room. Clients SHOULD display further information to help identify the user, +such as User ID, encryption verification status, rooms you share with the user, +etc. Care should be taken to balance the importance of preventing attacks while +avoiding overloading the user with too much information or raising false +positives. Another abuse vector is allowed by the ability for users to rescind knocks. This is to help users in case they knocked on a room accidentally, or simply