MSC4311: Ensuring the create event is available on invites and knocks

[turt2live]

Rendered

Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published with my role as a member of the SCT.

Dependencies:

• MSC4291: Room IDs as hashes of the create event #4291

---

SCT Stuff:

FCP tickyboxes

MSC checklist

[turt2live]

Implementation requirements:

• Server (returning stripped state)
• Server (receiving stripped state) - See comment below
• Client (receiving stripped state)

[turt2live]

Ruma (server; sending):

• federation-api: merge knock into membership, allow non-stripped events to be represented in membership handshakes, unstable support for MSC4311 ruma/ruma#2171
• client-api: allow non-stripped events to be represented in sync_events, unstable support for MSC4311 ruma/ruma#2173

[tulir]

Meowlnir (client/bot replacing room ID parsing with creator parsing in invite antispam): maunium/meowlnir@eeccd4a

[turt2live]

Though servers haven't actually added the validation on the stripped state yet, per the migration section of the MSC, no one has indicated that it's a nightmare to do so. I'm inclined to consider that "implementation" for the purposes of starting FCP, but welcome (particularly SCT) opinions on whether that's valid.

[Kladki]

Server returning and receiving: https://gitlab.com/famedly/conduit/-/commit/532b17ade86b4373db9f3bcca6af6815dd9b5b10

[turt2live]

This MSC now requires all stripped state events to be PDUs over federation. I believe element-hq/synapse#18822 and matrix-org/complement#796 demonstrate it's not impossible, even if the code itself is bad.

[turt2live]

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

Checklist:

• Are appropriate implementation(s) specified in the MSC’s PR description?
• Are all MSCs that this MSC depends on already accepted?
• For each new endpoint that is introduced:
  • Have authentication requirements been specified?
  • Have rate-limiting requirements been specified?
  • Have guest access requirements been specified?
  • Are error responses specified?
    • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
      • If a new errcode is introduced, is it clear that it is new?
• Will the MSC require a new room version, and if so, has that been made clear?
  • Is the reason for a new room version clearly stated? For example, modifying the set of redacted fields changes how event IDs are calculated, thus requiring a new room version.
• Are backwards-compatibility concerns appropriately addressed?
• Are the endpoint conventions honoured?
  • Do HTTP endpoints use_underscores_like_this?
  • Will the endpoint return unbounded data? If so, has pagination been considered?
  • If the endpoint utilises pagination, is it consistent with the appendices?
• An introduction exists and clearly outlines the problem being solved. Ideally, the first paragraph should be understandable by a non-technical audience.
• All outstanding threads are resolved
  • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
• While the exact sections do not need to be present, the details implied by the proposal template are covered. Namely:
  • Introduction
  • Proposal text
  • Potential issues
  • Alternatives
  • Dependencies
• Stable identifiers are used throughout the proposal, except for the unstable prefix section
  • Unstable prefixes consider the awkward accepted-but-not-merged state
  • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
• Changes have applicable Sign Off from all authors/editors/contributors
• There is a dedicated "Security Considerations" section which detail any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.". See RFC3552 for things to think about, but in particular pay attention to the OWASP Top Ten.

[turt2live]

Though I've just pushed a refactor of this MSC, the vast majority has had healthy discussion prior and appears to have settled and should therefore be ready for FCP. There's an open question on the implementation requirements, but I hope to at least collect tickyboxes until implementation can be drafted (possibly next week).

@mscbot fcp merge

[richvdh]

@mscbot concern inconsistency between event types feels like an unnecessary complication

[kegsay]

Similar treatment is applied to other stripped state events for uniformity.

But why, aside from vdh's general ick feeling of having 2 data types in the same array? By doing it for all events:

• we add more bandwidth to invites
• we don't gain any more security as the events can't be verified via their auth chains
• we risk giving the impression that we are authorising all events in invite_room_state, which we ain't.

To fix the ick, I'd rather we moved the create event to be a new key outside of invite_room_state and leave invite_room_state as-is, although that would either be backwards incompatible (the create event would be missing from invite_room_state) or duplicate the create event fields if we keep the create event in invite_room_state for a while.

[richvdh]

For reference: this follows on from two previous threads (1, 2) where this was discussed in detail.

we add more bandwidth to invites

This feels negligible though.

we don't gain any more security as the events can't be verified via their auth chains

It is not proposed as a security improvement; rather as one that makes the API more consistent.

we risk giving the impression that we are authorising all events in invite_room_state, which we ain't.

I really don't buy this argument. The fact that an event is passed over the federation API doesn't say anything to me about whether it is authorised or not.

I'll also re-emphasise that if you stick to the "full PDUs make people think that they are authorised" argument, then we have to do something different here for pre-v12 rooms (see previous thread) which is also gnarly.

[kegsay]

This [additional bandwidth] feels negligible though.

To you perhaps, but this is the main reason why we have the concept of stripped state events at all vs sending full-fat PDUs.

I don't feel strongly on this. Having stripped state always be the full-fat PDU seems fine.

[richvdh]

For reference: this follows on from two previous threads (1, 2) where this was discussed in detail.

we add more bandwidth to invites

This feels negligible though.

we don't gain any more security as the events can't be verified via their auth chains

It is not proposed as a security improvement; rather as one that makes the API more consistent.

we risk giving the impression that we are authorising all events in invite_room_state, which we ain't.

I really don't buy this argument. The fact that an event is passed over the federation API doesn't say anything to me about whether it is authorised or not.

I'll also re-emphasise that if you stick to the "full PDUs make people think that they are authorised" argument, then we have to do something different here for pre-v12 rooms (see previous thread) which is also gnarly.

[richvdh]

@mscbot resolve inconsistency between event types feels like an unnecessary complication

[richvdh]

thanks

[richvdh]

some light editing of the intro

[richvdh]

Suggested change

	# MSC4311: Ensuring the create event is available on invites and knocks
	# MSC4311: Ensuring the create event is available on invites

[richvdh]

Suggested change

	Historically, when processing an invite or knock, safety tooling would parse the room ID despite
	[being opaque](https://spec.matrix.org/v1.15/appendices/#room-ids) to determine the server which
	originally created the room. If that server was considered abusive, the incoming invite or outbound
	knock may be rejected or blocked early by the tooling. This approach is preferred because the user
	sending the invite may not be on the same server as the user who created the room, though both sender
	and creator are checked by safety tooling.
	Historically, when processing an incoming invite or outgoing knock, safety tooling would parse the room ID despite
	[being opaque](https://spec.matrix.org/v1.15/appendices/#room-ids), to determine the server which
	originally created the room. If that server was considered abusive, the invite or
	knock may be rejected or blocked early by the tooling. Note that checking the domain of the
	sender of an invite is inadequate, because the sender may not be on the same server as the
	user who created the room.

[richvdh]

Suggested change

	This MSC shifts the `m.room.create` event to a *required* stripped state event, and imposes validation
	To mitigate the problem in the case of invites,
	this MSC shifts the `m.room.create` event to a *required* stripped state event, and imposes validation