From 258aba5fedf1fff17429494ff25f3a46827e8e5b Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Mon, 7 Jan 2019 13:09:21 -0700 Subject: [PATCH] Incorporate MSC1693 This is largely blatant copy/paste from the MSC with some formatting done to tidy it up a bit. --- specification/rooms/v2.rst | 43 +++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/specification/rooms/v2.rst b/specification/rooms/v2.rst index a000f056..b04f94b4 100644 --- a/specification/rooms/v2.rst +++ b/specification/rooms/v2.rst @@ -155,7 +155,8 @@ Iterative auth checks state event is not allowed by the authorization rules, then the event is ignored. If a ``(event_type, state_key)`` key that is required for checking the authorization rules is not present in the state, then the appropriate - state event from the event's ``auth_events`` is used. + state event from the event's ``auth_events`` is used if the auth event is + not rejected. Algorithm +++++++++ @@ -179,3 +180,43 @@ The *resolution* of a set of states is obtained as follows: .. _`authorization rules`: ../server_server/unstable.html#authorization-rules + +Rejected events ++++++++++++++++ + +Events that have been rejected due to failing auth based on the state at the +event (rather than based on their auth chain) are handled as usual by the +algorithm, unless otherwise specified. + +Note that no events rejected due to failure to auth against their auth chain +should appear in the process, as they should not appear in state (the algorithm +only uses events that appear in either the state sets or in the auth chain of +the events in the state sets). + +.. admonition:: Rationale + + This helps ensure that different servers' view of state is more likely to + converge, since rejection state of an event may be different. This can happen if + a third server gives an incorrect version of the state when a server joins a + room via it (either due to being faulty or malicious). Convergence of state is a + desirable property as it ensures that all users in the room have a (mostly) + consistent view of the state of the room. If the view of the state on different + servers diverges it can lead to bifurcation of the room due to e.g. servers + disagreeing on who is in the room. + + Intuitively, using rejected events feels dangerous, however: + + 1. Servers cannot arbitrarily make up state, since they still need to pass the + auth checks based on the event's auth chain (e.g. they can't grant themselves + power levels if they didn't have them before). + 2. For a previously rejected event to pass auth there must be a set of state + that allows said event. A malicious server could therefore produce a + fork where it claims the state is that particular set of state, duplicate the + rejected event to point to that fork, and send the event. The + duplicated event would then pass the auth checks. Ignoring rejected events + would therefore not eliminate any potential attack vectors. + + +Rejected auth events are deliberately excluded from use in the iterative auth +checks, as auth events aren't re-authed (although non-auth events are) during +the iterative auth checks.