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

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