MSC4349: Causal barriers and enforcement #4349
Conversation
Gnuxie
changed the title
Gnuxie
changed the title
|
Context: This MSC was made because MSC4345 described an informal version of the deferred authorization causal enforcement model discussed in this MSC. Which uncovered the problem of causal barrier conflicts. |
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- General sense of agreement among protocol developers towards adopting definitions
- Metric: FCP starts successfully (likely ignoring the checkbox for "has implementation").
| all room participants. Unfortunately, this already can happen today, | ||
| it's just room participants with a more complete synchronisation are | ||
| unable to notice. And anyone with a partial synchronisation, such as a | ||
| new joiner, can. |
There was a problem hiding this comment.
To be honest I get confused every time i revisit this. It's not actually clear to me what does currently happen here.
| If knowledge is incomplete, the server makes an immediate decision to | ||
| soft fail the concurrent event (which is what happens currently in | ||
| Matrix). |
There was a problem hiding this comment.
There's more nuance to this, in that the way this decision gets made is by determining if the event is authorizable with respect to current authorization state rather than the cited state from auth_events.
| This would allow us to immediately begin to use consistent terminology | ||
| within the context of [MSC4345: Server key identity and room | ||
| membership](https://github.com/matrix-org/matrix-spec-proposals/pull/4345#discussion_r2336627872) | ||
| and other MSC's which may have security concerns that cannot be | ||
| expressed without this understanding. |
There was a problem hiding this comment.
This should come before the suggested solutions. Also the link is broken and the apostrophe shouldn't be there
|
|
||
| - None considered | ||
|
|
||
| ## Security considerations |
There was a problem hiding this comment.
It might not be safe to use auth_events to create a vector clock frontier for a sender.
This is because if the sender joined via a partial synchronisation and only have a snapshot of the current auth state from /make_join then they can be forced to indirectly reference unauthorized events. Implementations may also be lazy about recursively verifying auth_state from prev_events when merging branches too. Which absolutly removes the ability to use prev_events to form a vector clock frontier.
There was a problem hiding this comment.
Effectively this makes it impossible for someone rebuilding the entire auth_chain to form a vector clock frontier from the auth_events and prev_events to reason about the causal knowledge of a sender. Because the frontier can be full of random events that the sender hasn't bothered to either verify or authorize.
There was a problem hiding this comment.
And that stops ANYONE from being able to reliably reason about causal barrier violations.
There was a problem hiding this comment.
Blue is trying to ban yellow in order to erase yellow's events. But new joiners can't tell wtf is going on here and can't even tell that there is a causal barrier violation because Blue has been tricked by Green into tying in the events Blue tried to erase.
Essentially, Yellow's membership is a causal predecessor of Blue's ban on yellow. The events are not conflicting. But blue has been tricked into referencing a yellow event which would normally be soft failed because of the causal barrier from Blue's ban on yellow. A ban that doesn't include yellow's event as a casual predecessor.
There was a problem hiding this comment.
probably easier to understand if it looks like this
There was a problem hiding this comment.
There's no reliable way to prevent this. It's impossible.
There was a problem hiding this comment.
Problem discussion moved to #4353
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com