Re: [MLS] Virtual Interim minutes

[Richard Barnes <[e-mail]>]

On Wed, Jan 29, 2020 at 6:48 PM Benjamin Beurdouche <
[e-mail]> wrote:

>
> > #285 - Get rid of ignored proposals.
> > I had added "ignored" to the Commit message to allow the Committer to
> indicate Proposals that they had received, but was not committing.  Brendan
> makes a plausible case in the PR that this distinction is not worthwhile,
> and this cleans it up.  Please speak up now if you have a concern /
> objection to merging this PR.
>
> I am obviously against allowing a network attacker to arbitrarily truncate
> the proposals from someone. The explicit acknowledgement of ignored
> proposals lets the sender of the proposal know that the committer actually
> received, processed and discarded the proposal. This is obviously way
> better that not knowing if the proposal even reached the committer.
>

Note that the current proposal ACKs all "valid" proposals, since the
Committer MUST include all valid proposals in the commit.  The only thing
that are omitted are proposals that would have no effect on the final group
state.  So the attacker cannot arbitrarily suppress proposals without being
noticed.  For example, an otherwise valid Add or Remove will never be
omitted, so if an endpoint sent an Add/Remove and it didn't end up in the
Commit, then he knows it was not received by the committer.

AFAICT the only interesting ambiguity arises when there are two Updates, in
which case the current spec doesn't specify which of the two should be
selected and which invalidated.  In such a situation, with the current
proposal, if you send two Updates and see the earlier one in the Commit,
you don't know if the later one didn't arrive or if the committer just
didn't choose it.  But this can be easily resolved by specifying that the
committer always chooses the Update with the highest generation for the
sender, so that if a Commit arrives that includes an update with a lower
generation than the highest you sent, then you know the later ones weren't
received.

In other words, if we make that fix, the only cases where you don't get an
ACK are the cases where the proposal wouldn't affect the protocol anyway.
Namely, Updates that are overwritten by another Update or a Remove.  So the
protocol ACKs everything that is meaningful to the protocol.

(Brendan also makes the practical point in the PR that it doesn't matter
for client behavior whether a missing proposal was received or not --
either way, it needs to retransmit to get the job done.)

The best argument I can imagine for keeping "ignored" is extensibility --
the analysis of whether something affects the protocol state might not be
so simple with some future type of Proposal.  But I'm having trouble
thinking of any example where this would be the case.

Could you live with something like the following?

1. Resolve the above-noted ambiguity about multiple Updates for the same
leaf
2. State explicitly that the only Proposals that may be omitted from a
Commit are:
  - Invalid proposals (e.g., because of a bad signature, parsing error,
reference to a non-existent leaf)
  - Proposals whose effect on the tree is overwritten by another proposal,
which at this point includes only:
    - Updates for a leaf prior to the latest Update received by the
committer
    - Updates for a leaf for which there is a Remove in the epoch

ISTM that that ensures that a Proposal is ACK'ed iff it matters to the
protocol.

--RLB