Re: [MLS] More clarity around validating proposals

[Richard Barnes <[e-mail]>]

Inline...

On Fri, May 13, 2022 at 2:04 PM Mularczyk Marta <[e-mail]>
wrote:

> Hi Richard,
>
> Thanks for the input! In fact, we’re all for downgrading MUSTs to SHOULDs.
> I think it still makes sense to collect all the rules / guidance from the
> RFC into a single section 13.4. It would contain:
>
>
>    1. Properties that a committed vector of proposals MUST satisfy. They
>    are required for correctness or security of MLS.E.g.
>       1. There MUST NOT be a proposal removing the committer
>       2. ExternalInit MUST only be used in external commit
>       3. The signature MUST verify
>    2. Properties that a committed vector of proposals SHOULD satisfy,
>    i.e., general guidance). E.g.
>       1. There SHOULD be at most one proposal affecting a leaf
>
>
Sounds good to me.  A few other ideas:

- ExternalInit MUST NOT appear outside of an external Commit (i.e., only if
sender.type == new_member)
- There SHOULD NOT be an Update proposal for the committer (in particular,
no Updates by value)
- There SHOULD NOT be Update and Remove proposals for the same leaf
- There SHOULD NOT be more than one GroupContextExtensions proposal (they
will overwrite each other)
- Might say "SHOULD NOT be more than one" instead of "SHOULD be at most one"

Look forward to the PR.


> > Though I have to say I don't love the idea of trying to implement the
> logic to build such a maximal list.
>
> Very simple :) Say you have a proposal list L. To build a maximal valid
> list, start with an empty list LVal. Then for each P in L, do: if LVal with
> P appended is valid, append P to LVal. Else, continue.
>

That gives you *a* maximal proposal list -- but maybe not the one that's
right for the situation!  It's dependent on the order in which you consider
P in L, so if there are two incompatible proposals, you'll take the first
one.  Might or not be the right outcome.  There are good algorithms here,
they're just more complicated than "whatever the application says" :)

--Richard


>
> Best,
> Marta
>
> ------------------------------
> *From:* MLS <[e-mail]> on behalf of Richard Barnes <[e-mail]
> >
> *Sent:* Friday, May 13, 2022 5:05:28 PM
> *To:* Mularczyk Marta
> *Cc:* [e-mail]
> *Subject:* Re: [MLS] More clarity around validating proposals
>
> Hi Marta,
>
> Thanks for thinking about this stuff, these are good issues to clarify.  I
> agree with your analysis, and the conclusion that the current text is
> ambiguous.  Though I think some of the ambiguity may have been intentional,
> to allow for the sorts of policies you describe.
>
> It seems like there's a prerequisite question as to whether we need to be
> prescriptive about these things.  One could imagine leaving the set of
> proposals committed up to the application.  Different choices by the
> application would have implications that would be worth discussing in the
> spec (e.g., the members could refuse to commit a Remove sent by an external
> proposer), but both the risks and the possibilities to mitigate them seem
> more specific to application deployment contexts, as opposed to core parts
> of the protocol.  Personally, I have a pretty strong preference for this
> option.
>
> If we were going to do that, I think the major impact would just be to
> downgrade the MUSTs on this front to SHOULDs.  We should probably provide
> some notes of the general character you describe, but we wouldn't need to
> be quite so precise because we would just be providing guidance, not hard
> requirements.
>
> If we're going to go down the path you suggest, the text changes you
> propose sound about right.  Though I have to say I don't love the idea of
> trying to implement the logic to build such a maximal list.  It might be
> worth noting that it's possible for there to be multiple lists that are
> maximal in this sense, e.g. if two proposals are mutually exclusive with
> each other but compatible with the others.
>
> --Richard
> On Thu, May 12, 2022 at 12:44 PM Mularczyk Marta <
> [e-mail]> wrote:
>
>> Hi all,
>>
>> Me, Tom Leavy and Joël Alwen think that the text in the RFC around
>> validating proposals, choosing which proposals go into a commit and how to
>> validate a received commit could do with a bit more work.
>>
>> The root issue is that Section 13.2 states “The sender of a Commit MUST
>> include all valid proposals that it has received during the current epoch.
>> Invalid proposals include, for example, proposals with an invalid signature
>> or proposals that are semantically invalid, such as an Add when the sender
>> does not have the application-level permission to add new users.” There are
>> two intertwined issues with this text:
>>
>>    1. The qualifier “MUST”
>>    2. The text is too vague about what a “valid Proposal” is. E.g. it
>>    could be interpreted to mean a Proposal is “valid” relative to the current
>>    group state: Can it be applied to the group as it stands now? Then it’s
>>    “valid”.
>>
>>
>> Put simply, it doesn’t make sense to only validate proposals
>> individually. Instead one should validate if the full list of proposals can
>> be committed. Indeed, other parts of the RFC enforce validation steps that
>> apply to the full list. E.g.
>>
>>    - A ReInit proposal MUST be the only one in the commit, and other
>>    existing proposals SHOULD be preferred (13.2.1).
>>
>>
>>    - Out of multiple proposals affecting the same leaf, the committer
>>    MUST choose an arbitrary one (13.2, “If there are multiple (…)”).
>>
>>
>>    - Out of multiple PSK proposals with the same ID, the committer MUST
>>    choose an arbitrary one (13.2).
>>
>>
>> In fact, once extensions come into play there are likely many more
>> similar situations, even ones affecting lists of otherwise benign proposals
>> (e.g. Add/Remove). Suppose a chat app is built on MLS with a custom room
>> moderator roles extension. The app wants MLS to enforce two rules: Only
>> mods can Add/Remove. Rooms should always have at least 1 Mod. Here’s how
>> the RFC’s current text can become a problem: A and B are the only mods in a
>> room. A makes proposal P1 that removes B. Meanwhile, B makes prop P2 that
>> removes A. C gets both proposals. What should C do?
>>
>>    - Option 1: validate & cache both proposals. → Problem: C can no
>>    longer issue a commit as it “MUST include all valid proposals”.
>>    (Alternatively, it does commit to both as instructed by the RFC which
>>    leaves the room without a mod.)
>>
>>
>>    - Option 2: validate & cache the first prop received (say, P1), but
>>    reject P2 as validating both means C can’t commit. → Problem: If someone
>>    else commits to P2 by ref. C can’t process the commit as it doesn’t “know”
>>    P2.
>>
>>
>> So, to clean all this up a bit more we are working on a PR with 2 main
>> changes:
>>
>>    1. In 13.2, replace “The sender of a Commit MUST include all valid
>>    proposals that it has received“ by ”The sender of a Commit MUST commit to a
>>    maximal valid list of proposals. The conditions making a list of proposals
>>    'valid' for an epoch are described in Section 13.4. A valid list is
>>    'maximal' if adding any other received proposal would result in an invalid
>>    list.“
>>    2. Add Section 13.4 which collects all rules for validating proposals
>>    (currently in 13.2, 13.1, 11.1, 8.3) into 3 procedures: validating an
>>    incoming proposal, validating a list of proposals on creating a commit and
>>    on receiving a commit.
>>
>>
>> We’d be happy to hear what people think about this!
>>
>> Marta
>>
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>>
>