Merge 6862c70e2c into cbf1854b93

content/client-server-api/modules/end_to_end_encryption.md

@@ -1517,19 +1517,8 @@ The plaintext payload is of the form:
 The type and content of the plaintext message event are given in the
 payload.
 
-If a client has multiple sessions established with another device, it
-should use the session from which it last received and successfully
-decrypted a message. For these purposes, a session that has not received
-any messages should use its creation time as the time that it last
-received a message. A client may expire old sessions by defining a
-maximum number of olm sessions that it will maintain for each device,
-and expiring sessions on a Least Recently Used basis. The maximum number
-of olm sessions maintained per device should be at least 4.
-
 ###### Validation of incoming decrypted events
 
-{{% changed-in v="1.15" %}} Existing checks made more explicit, and checks for `sender_device_keys` added.
-
 After decrypting an incoming encrypted event, clients MUST apply the
 following checks:
 
@@ -1558,8 +1547,6 @@ Any event that does not comply with these checks MUST be discarded.
 
 ###### Verification of the sending user for incoming events
 
-{{% added-in v="1.15" %}}
-
 In addition, for each Olm session, clients MUST verify that the
 Curve25519 key used to establish the Olm session does indeed belong
 to the claimed `sender`. This requires a signed "device keys" structure
@@ -1580,7 +1567,7 @@ Ownership of the Curve25519 key is then established in one of two ways:
 1.  Via [cross-signing](#cross-signing). For this to be sufficient, the
     device keys structure must be signed by the sender's self-signing key,
     and that self-signing key must itself have been validated (either via
-    [explicit verification](#device-verification) or a "trust on first use" (TOFU) mechanism).
+    [explicit verification](#device-verification) or a TOFU mechanism).
 2.  Via explicit verification of the device's Ed25519 signing key, as
     contained in the device keys structure. This is no longer recommended.
 
@@ -1588,6 +1575,15 @@ A failure to complete these verifications does not necessarily mean that
 the session is bogus; however it is the case that there is no proof that
 the claimed sender is accurate, and the user should be warned accordingly.
 
+If a client has multiple sessions established with another device, it
+should use the session from which it last received and successfully
+decrypted a message. For these purposes, a session that has not received
+any messages should use its creation time as the time that it last
+received a message. A client may expire old sessions by defining a
+maximum number of olm sessions that it will maintain for each device,
+and expiring sessions on a Least Recently Used basis. The maximum number
+of olm sessions maintained per device should be at least 4.
+
 ###### Recovering from undecryptable messages
 
 Occasionally messages may be undecryptable by clients due to a variety