MSC4099: Participation based authorization for servers in the Matrix DAG #4099
Conversation
mweh idc about getting 5000.
turt2live
added
requires-room-version
| - A way for servers to advertise to other servers about rooms that their users are likely to join, | ||
| so that these rooms can be optionally preloaded and cached. | ||
|
|
||
| This is a more specific component and redesign of the general idea of [MSC3953: Server capability DAG](https://github.com/Gnuxie/matrix-doc/blob/gnuxie/capability-dag/proposals/3953-capability-dag.md). |
There was a problem hiding this comment.
I don't think so, and I don't know yet. Is that alright?
| DAG. This MSC does not define or ammend a state resolution algorithm, since there are serveral possible | ||
| routes that can be explored with other MSCs. | ||
|
|
||
| The key merits of this proposal are: |
There was a problem hiding this comment.
I'm a bit unclear on what the actual problem being solved is here. I agree that because servers can spoof user events, you could model membership of DAGs via servers rather than users. However, shouldn't we be moving towards membership of rooms being tied more tightly to actual users & devices (i.e. cryptographically constrained group membership) rather than giving up and modelling participation just by servers?
In terms of the merits here:
The ability to deny servers from adding events to the DAG.
Do we not get this via ACLs?
The ability for clients and bots to examine joining servers before accepting any PDU from them into the room.
Hm, so this would let an AS on a server sniff traffic and somehow authorise it before it reaches other users in the room on that server?
Arbitrary knock logic for servers.
I'm failing to follow how this works. Is the idea that joins can be delegated to a client on a target server so the client can decide whether the joiner server is allowed to join or not?
So is the idea here: "Provide a way for clients to subscribe to all events attempting to federate with the server, and authorise them before they enter the room DAG?". If so, I wonder if a less invasive mechanism could be used - effectively a standardised API to inspect events before federation rules kick in, rather than changing the entire concept of membership?
(This also reminds me a bit of pseudousers in #1777 and whatever travis is up to in #4049, in terms of letting servers act as a first-class citizen rather than requiring traffic to be linked to users. Historically this has not gone anywhere, though: the accountability of actually linking traffic to users rather than servers seems desirable).
There was a problem hiding this comment.
However, shouldn't we be moving towards membership of rooms being tied more tightly to actual users & devices (i.e. cryptographically constrained group membership) rather than giving up and modelling participation just by servers?
I do not think this MSC is not incompatible with cryptographically constraining user membership. Since this MSC can still be used in a DAG that has user membership in addition to server participation. However, there is another conversation to be had over whether Matrix should be going in this direction. However, it is not relevant to this MSC, that discussion is more relevant to #3953. So as a digression, while I'm not prepared to argue in the opposite direction right now, I would at least like to explore the alternative, even if it is opposed to the goal of eliminating meta data etc. Since for large public Matrix rooms it's not exactly clear to me yet how device centric membership, and pseudo identity etc is going to protect against data farming/mining by joining lots of public rooms etc. At least not in isolation and when most people are going to have the same profile information in all public rooms. Since for this to be effective the way people are using Matrix would also have to change. From what I have seen so far, with these proposals you are designing a protocol that suits a use case that is entirely different to the way Matrix is being used by the community today. Again, I see this as a digression. And I concede that I could be grossly misinformed about this, and I'm yet to develop my thoughts more concretely here. This is not the purpose of the MSC.
Do we not get this via ACLs?
No, and you know this as well as I do. Server ACL has been accidentally bypassed by server implementations not implementing it properly before, and with wider adoption of Matrix this will happen again. Additionally, there is no protection against a server deliberately leaking events between normal and malicious servers (in both directions), and no tooling to detect these leaks. There is also a limit to the number of servers that can be added to server ACL (around 512?), it really needs replacing. It requires all participating servers to be using the room in good faith, that is not going to be a reality forever.
Hm, so this would let an AS on a server sniff traffic and somehow authorise it before it reaches other users in the room on that server?
No, this was specific to sniffing the knock EDU during the revised server join handshake.
I'm failing to follow how this works. Is the idea that joins can be delegated to a client on a target server so the client can decide whether the joiner server is allowed to join or not?
Yes, the knock EDU is used as a way to get the clients to see that a server is wanting to join the room, granted there could be another better way to do this.
So is the idea here: "Provide a way for clients to subscribe to all events attempting to federate with the server, and authorise them before they enter the room DAG?"
No, again, the proposal is to make servers send an EDU to the room when they want to join, so that clients (and therefore admins, or at least their tooling) can vet the servers before allowing them to join and be authorized to send any events. Once they have been vetted, all authorization is done via auth rules. The idea is that there isn't a way in the auth rules for a joining server to create a valid PDU until a special event m.server.participation exists that references their server name. And this event has to be created by a room admin once they know the joining server exists. They can also pre-empt the existence of joining servers and setup m.server.participation events for them in advance. I guess now that I have explained this as such, it does look a lot like an allow list, but with a mechanism for it to be automatically updated quickly enough not to cause too much disruption.
There was a problem hiding this comment.
I've updated the introduction to the proposal since I think you read that and it mislead you. It was probably too abstract, my bad.
There was a problem hiding this comment.
(Those proposals are interesting though, I'll give them a look)
There was a problem hiding this comment.
Do we not get this via ACLs?
The specification does not recommend that servers must (or even should) soft fail events from servers matching m.room.server_acl's deny. So you can't even rely on leaks to be mitigated that way. The specification likely can't make that recommendation either, because you'd have to think about what that would imply for a new server joining the room that goes on to replicate the room's history afresh.
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com