payload: {"action":"created","issue":{"url":"https://api.github.com/repos/matrix-org/matrix-doc/issues/1130","repository_url":"https://api.github.com/repos/matrix-org/matrix-doc","labels_url":"https://api.github.com/repos/matrix-org/matrix-doc/issues/1130/labels{/name}","comments_url":"https://api.github.com/repos/matrix-org/matrix-doc/issues/1130/comments","events_url":"https://api.github.com/repos/matrix-org/matrix-doc/issues/1130/events","html_url":"https://github.com/matrix-org/matrix-doc/issues/1130","id":299695005,"node_id":"MDU6SXNzdWUyOTk2OTUwMDU=","number":1130,"title":"m.room.aliases is broken and here's how to fix it:","user":{"login":"jevolk","id":4682706,"node_id":"MDQ6VXNlcjQ2ODI3MDY=","avatar_url":"https://avatars1.githubusercontent.com/u/4682706?v=4","gravatar_id":"","url":"https://api.github.com/users/jevolk","html_url":"https://github.com/jevolk","followers_url":"https://api.github.com/users/jevolk/followers","following_url":"https://api.github.com/users/jevolk/following{/other_user}","gists_url":"https://api.github.com/users/jevolk/gists{/gist_id}","starred_url":"https://api.github.com/users/jevolk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jevolk/subscriptions","organizations_url":"https://api.github.com/users/jevolk/orgs","repos_url":"https://api.github.com/users/jevolk/repos","events_url":"https://api.github.com/users/jevolk/events{/privacy}","received_events_url":"https://api.github.com/users/jevolk/received_events","type":"User","site_admin":false},"labels":[{"id":1046862329,"node_id":"MDU6TGFiZWwxMDQ2ODYyMzI5","url":"https://api.github.com/repos/matrix-org/matrix-doc/labels/client-server","name":"client-server","color":"343da3","default":false},{"id":476961916,"node_id":"MDU6TGFiZWw0NzY5NjE5MTY=","url":"https://api.github.com/repos/matrix-org/matrix-doc/labels/feature","name":"feature","color":"84b6eb","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2018-02-23T12:24:23Z","updated_at":"2019-05-02T23:45:33Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The room aliases system has several fundamental defects which render it unusable. These include security weaknesses. This issue will proffer two remedies to be applied in stages which will repair these defects and allow the system to be used as intended.\r\n\r\n### Background\r\n\r\nThe room aliases system is fundamental to the operation of the entire Matrix communication protocol. Aliases provide human-readable addressing for Matrix chat rooms. Without aliases, rooms can only be addressed by a single globally unique opaque identifier, the `room_id`. As an analogy, if the `room_id` was a networked computer's [IP address](https://en.wikipedia.org/wiki/IP_address), then room aliases would be the [domain names](https://en.wikipedia.org/wiki/Domain_name) pointing to the IP address. Contrary to an IP address on the internet, the Matrix protocol lacks any means by which to provide routing for `room_id`'s, for example, by failing to provide an overlaying [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table). Due to this limitation, room aliases are required for finding rooms within the Matrix system.\r\n\r\n#### How they work\r\n\r\nThe specification for room aliases is spread out over many places. They are first found in the Matrix [Introduction](https://matrix.org/docs/spec/intro.html), section 2.5.1. Their grammar is further detailed in the Matrix [Appendix](https://matrix.org/docs/spec/appendices.html) materials. They are stored and federated through a \"state event\" with the type `m.room.aliases` specified in the Client-Server protocol [r0.3.0 section 10.5.1](https://matrix.org/docs/spec/client_server/r0.3.0.html#m-room-aliases). Additionally, a suite of endpoints has been made available in the Client-Server protocol [r0.3.0 section 7.2](https://matrix.org/docs/spec/client_server/r0.3.0.html#room-aliases).\r\n\r\nExample of the `m.room.aliases` event content:\r\n```\r\n\"content\":\r\n{\r\n    \"aliases\":\r\n    [\r\n        \"#somewhere:localhost\",\r\n        \"#another:localhost\"\r\n    ]\r\n}\r\n```\r\n### Defects\r\n\r\n#### Poor key selection and value typing\r\n\r\nThe key of the `m.room.aliases` event (the `state_key`) is a homeserver domain and the value (`content`) an array of the aliases. With the key of the event being a homeserver domain, only one event can be used to query the aliases provided by a specific homeserver. To provide multiple aliases, an array type was selected for the content.\r\n\r\nThis immediately confuses client developers. Developers are accustomed to modifying the state of the room through the [6.4.1 rooms/state PUT](https://matrix.org/docs/spec/client_server/r0.3.0.html#put-matrix-client-r0-rooms-roomid-state-eventtype-statekey) endpoint. Intuitively, developers assume that they should faithfully copy the existing event content, update it with changes, and then submit it to that endpoint. This may or may not be the case depending on the implementation, but the [7.2 suite](https://matrix.org/docs/spec/client_server/r0.3.0.html#room-aliases) is also redundantly provided to perform these operations.\r\n\r\n#### Lack of authority over the homeserver's specific key\r\n\r\nIdeally, homeservers choose the aliases they believe best describe the room. For example, one homeserver may choose `#wines:foo.com` while another homeserver chooses `#sommeliers:bar.fr`. The chosen names are how users of their homeserver may find the room. If those aliases are changed or disappear, their users *may no longer be able to find the room*. The problem here is that an operator of any server with access to change one `m.room.aliases` event has access to change all of the other aliases events *for other servers apart from their own*.\r\n\r\n### Related work\r\n\r\nA similar issue focusing specifically on the security implication was brought up by #625 over two years ago and it remains open with zero ideas. Not long after, #654 mentions an endpoint which is used by Riot but has remained unspecified for *over three years* as evidenced by #417. Overall, no substantive attempts have been made to solve this problem. Instead, its brokenness is assumed as gospel and more is built on top of the error rather than solving it.\r\n\r\n### Solution\r\n\r\nBy resolving this issue here, this effort hopes to:\r\n- Close all of the above issues and make the aliases system work as intended without all of the cautionary caveats and warnings.\r\n- Eliminate the secret endpoints used by Riot.\r\n- Eliminate the Client-Server 7.2 endpoint section.\r\n\r\n#### Stage One\r\n\r\nThe first phase to address this problem is simple: implementations deny homeservers from updating `m.room.aliases` events which don't belong to them. In other words, the room's state machine denies a transition from an `m.room.aliases` event where `state_key` != `origin`.\r\n\r\n#### Stage Two\r\n\r\nThe `m.room.aliases` event is replaced with an `m.room.alias` event. The new event is appropriately keyed and valued. As an example, consider the following form:\r\n```\r\n\"origin\": \"foo.com\",\r\n\"type\": \"m.room.alias\",\r\n\"state_key\": \"#sommeliers:foo.com\",\r\n\"content\":\r\n{\r\n    /* available for discussion */\r\n}\r\n```\r\n\r\n### Conclusions\r\n\r\nThis problem exists because Matrix.org believes room state cannot be deleted. This is an erroneous belief. Room state is *de facto* deleted when it is the target of an `m.room.redaction` event. \r\n\r\nThe fact that Matrix.org has failed to *implement* deletions has leaked into the *specification* by building on this error by designing the content of the `m.room.aliases` event as an array such that it allows for aliases to be removed. This error has then lead matrix.org to the realizations of the above defects and has lead to further errors by way of the unspecified directory endpoints.\r\n\r\nMatrix.org will have to implement proper behavior of their room state machine when a state event is the target of a redaction. Whether or not the specification should be updated to indicate this behavior *de jure* may be a matter for another issue."},"comment":{"url":"https://api.github.com/repos/matrix-org/matrix-doc/issues/comments/488871012","html_url":"https://github.com/matrix-org/matrix-doc/issues/1130#issuecomment-488871012","issue_url":"https://api.github.com/repos/matrix-org/matrix-doc/issues/1130","id":488871012,"node_id":"MDEyOklzc3VlQ29tbWVudDQ4ODg3MTAxMg==","user":{"login":"richvdh","id":1389908,"node_id":"MDQ6VXNlcjEzODk5MDg=","avatar_url":"https://avatars1.githubusercontent.com/u/1389908?v=4","gravatar_id":"","url":"https://api.github.com/users/richvdh","html_url":"https://github.com/richvdh","followers_url":"https://api.github.com/users/richvdh/followers","following_url":"https://api.github.com/users/richvdh/following{/other_user}","gists_url":"https://api.github.com/users/richvdh/gists{/gist_id}","starred_url":"https://api.github.com/users/richvdh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/richvdh/subscriptions","organizations_url":"https://api.github.com/users/richvdh/orgs","repos_url":"https://api.github.com/users/richvdh/repos","events_url":"https://api.github.com/users/richvdh/events{/privacy}","received_events_url":"https://api.github.com/users/richvdh/received_events","type":"User","site_admin":false},"created_at":"2019-05-02T23:45:33Z","updated_at":"2019-05-02T23:45:33Z","author_association":"MEMBER","body":"to follow up on part of this, jevolk defined stage one as:\r\n\r\n> The first phase to address this problem is simple: implementations deny homeservers from updating m.room.aliases events which don't belong to them. In other words, the room's state machine denies a transition from an m.room.aliases event where state_key != origin.\r\n\r\nAs far as I can tell, this has always been the case in practice, though it only made it into the written specification as of https://github.com/matrix-org/matrix-doc/pull/1591."}}
other: {"actor":{"display_login":"richvdh"}}