[MLS] External Proposals Guardrails

[Divyank Katira <[e-mail]>]

Hello,

A poorly designed implementation of external proposals could break the end-to-end encryption provided by MLS. A compromised server could arbitrarily add and remove group participants. While such tampering would be visible in the chat transcript, the utility of manual verification is diminished in large groups like the ones MLS enables.

I suggest two changes to nudge application developers towards a more secure design:

 - On the server side, given that the user/identity recovery cases that external proposals aim to address fall under the authentication service's purview, the initiation of such proposals can be constrained to the authentication service and not any preconfigured entity. This reduces trust on the delivery service provider in cases where a custom identity provider/SSO is used. This also fits better in the security considerations in the architecture document where authentication service compromise and delivery service compromise are treated differently, with the former leading to break of confidentiality, and the latter leading to denial of service.

 - On the client side, the protocol should signal to application developers that external proposals should be handled differently from other proposals. For example, an update proposal is a routine operation that can be committed automatically whereas an external proposal should require consent/manual consideration before commit.

I am happy to make concrete suggestions to the text if this sounds like a good idea.

Thanks,
Divyank