Incorporate MSC1693
This is largely blatant copy/paste from the MSC with some formatting done to tidy it up a bit.
@@ -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.
