diff --git a/proposals/4361-non-federating-member-auth.md b/proposals/4361-non-federating-member-auth.md new file mode 100644 index 00000000000..03c3da3c638 --- /dev/null +++ b/proposals/4361-non-federating-member-auth.md @@ -0,0 +1,29 @@ +# MSC4361: Non-federating Membership Authentication Rules + +Specification version 1.16. Room Version 12* § 2.2 (4)[1] is the sole clause within the Authentication Rules conditioned on the `m.federate` property. The `m.federate` property is an immutable declaration within the `m.room.create` event which isolates a room to a specific origin†. The sole condition to achieve a non-federating room is to deny events with a `sender` from a remote server. + +This method has several leakages. The "target" of an `m.room.member` event declared by its `state_key` is allowed to be a remote user. Compliant servers will both create, transmit‡ and accept such an event, only to find later it cannot be further acted upon. This specification change aims to correct this leakage and subsequent ⊥ by amending Rule `5. If type is m.room.member` prepending a new sub-rule `1. If the content of the m.room.create event in the room state has the property m.federate set to false, and the state_key domain of the event does not match the sender domain of the create event, reject.` shifting-up existing rules. + +## Alternatives + +Synapse has been observed in at least some cases to preclude the transmission and/or reception of events for non-federating rooms "manually." These restrictions are specified external to the authentication rules in some other places. This approach denudes the significance of authentication rules. One could ask: why specify _anything_ as authentication rules? This is the question a proponent of the status quo must bear. + +## Security Considerations + +While this proposal clearly increases security by reducing cross-origin leakage of events, the addition of any new restrictions is a theoretical Denial of Service vector which must be scrutinized during review. No such possibility is known to the author. + +## Potential Issues + +A new room version may be required. However, this author believes it is technically possible to backport this change to all prior room versions without any alteration to nominal correctness; leaked events would simply enter a failure state or remain ⊥. + +--- + +[1]: https://spec.matrix.org/v1.16/rooms/v12/#authorization-rules + +Special thanks to Dasha for assisting in the research for this proposal. + +* In addition to all earlier stable room versions. + +† Server or cluster sharing the same domain. + +‡ Synapse has been observed to impose certain restrictions external to the auth-rules. See: Alternatives for discussion.