Draft: draft-ietf-mls-protocol

Commentary: Ignored proposals do n't make sense to me . How can they possibly add value ? Also , re - structured section on Commits some . ! 
 I 'm afraid the flow chart might not quite be that simple . It is possible for there to be proposals that ( 1 ) do n't appear in the Commit and ( 2 ) do n't need to be re - sent . The simplest case is when a member sends two Update messages within an epoch . On the one hand , there 's no practical need for them both to be included in the Commit , since one will overwrite the other . On the other hand , at the same time , the new member should n't re - send the stale Update . The idea of the array was to provide a slot for these to be included in the Commit , but without the need for recipients to act on them . 
 On a separate note , it would be helpful if you could base your different PRs on master , to make the specific changes clearer . 
 In that specific example , the member is aware of all the Updates they 've sent and can know to only expect one to be included . In fact , the member can try to enforce a lot of things : Re - send if no Update was included . Re - send if the included Update is n't " recent enough . " Re - send if the included Update is n't the most recent . The member 's own sense of what should / shouldn't be included is what matters here , not the comitter 's . 
 I can agree that the difference between " Proposal got dropped somewhere in the ether " and " Proposal was consciously ignored by the Committer " is not really salient . I 'll post to the list to see if anyone else objects . 
 raised some concerns with this on the mailing list . I proposed a compromise there , of the form : that if a Committer receives two Updates proposals for the same leaf in the same epoch , then it MUST commit the latest one it received . 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 
 - How does that strike you ? 
 Is n't that what 's currently in the PR ? The only difference is " SHOULD prefer the most recent Update " because it 's not enforceable anyway 
 Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by : speaker : , by It received 3 comments . - - Last week , 8 pull requests were created , updated or merged . Last week , 7 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 1 pull request was merged . : purpleheart : , by - - Last week there were 3 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there were no stargazers . - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
A group member that has observed one or more Proposal messages within
an epoch MUST send a Commit message before sending application data.
This ensures, for example, that any members whose removal was
proposed during the epoch are actually removed before any application
information is transmitted.
Paragraph (version A):
The sender of a Commit message MUST include in it all valid Proposals
that the sender has received during the current epoch.  Invalid
Proposals include, for example, Proposals with an invalid signature
or Proposals that are semantically inconsistent, such as a Remove
proposal for an unoccupied leaf.  The Commit MUST NOT combine
Proposals sent within different epochs.  Despite these requirements,
it is still possible for a valid Proposal not to be covered by a
Commit, for example, because the sender of the Commit did not receive
the Proposal.  In such cases, the sender of the proposal can
retransmit the Proposal in the new epoch.  In the case where a
committer is processing Proposals where an Update proposal or a
Remove proposal exists for herself, this proposal MUST be ignored and
added to the list of discarded proposals in the Commit.
Paragraph (version A):
Each proposal covered by the Commit is identified by a ProposalID
value, which contains the hash of the MLSPlaintext in which the
Proposal was sent, using the hash function for the group's
ciphersuite.
Paragraph (version A):
The sender of a Commit message MUST include in it all proposals that
it has received during the current epoch.  Proposals that recipients
should implement are placed in the "updates", "removes", and "adds"
vector, according to their type.  Proposals that should not be
implemented are placed in the "ignored" vector.  For example, if two
Update proposals are issued for the same leaf, then one of them
(presumably the earlier one) should be ignored and the other
(presumably the later) should be added to the "updates" vector.
Paragraph (version B):
Each proposal covered by the Commit is identified by a ProposalID
value, which contains the hash of the MLSPlaintext in which the
Proposal was sent, using the hash function from the group's
ciphersuite.
Paragraph (version B):
A group member that has observed one or more proposals within an
epoch MUST send a Commit message before sending application data.
This ensures, for example, that any members whose removal was
proposed during the epoch are actually removed before any application
data is transmitted.
Paragraph (version B):
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.  If there are
multiple proposals that apply to the same leaf, the committer chooses
one and includes only that one in the Commit, considering the rest
invalid.  The committer MUST prefer any Remove received, or the most
recent Update for the leaf if there are no Removes.  If there are
multiple Add proposals for the same client, the committer again
chooses one to include and considers the rest invalid.
Paragraph (version B):
The Commit MUST NOT combine proposals sent within different epochs.
In the event that a valid proposal is omitted from the next Commit,
the sender of the proposal SHOULD retransmit it in the new epoch.
Paragraph (version A):
Construct an initial Commit object with "updates", "removes",
"adds", and "ignored" fields populated from Proposals received
during the current epoch, and an empty "path" field.
Paragraph (version B):
Construct an initial Commit object with "updates", "removes", and
"adds" fields populated from Proposals received during the current
epoch, and an empty "path" field.
Paragraph (version A):
Regardless of how messages are kept in sequence, implementations MUST
only update their cryptographic state when valid Commit messages are
received.  Generation of handshake messages MUST be stateless, since
the endpoint cannot know at that time whether the change implied by
the handshake message will succeed or not.
Paragraph (version A):
With this approach, the delivery service ensures that incoming
messages are added to an ordered queue and outgoing messages are
dispatched in the same order.  The server is trusted to resolve
conflicts during race-conditions (when two members send a message at
the same time), as the server doesn't have any additional knowledge
thanks to the confidentiality of the messages.
Paragraph (version B):
Regardless of how messages are kept in sequence, implementations MUST
only update their cryptographic state when valid Commit messages are
received.  Generation of Commit messages MUST NOT modify a client's
state, since the endpoint doesn't know at that time whether the
changes implied by the Commit message will succeed or not.
Paragraph (version B):
With this approach, the delivery service ensures that incoming
messages are added to an ordered queue and outgoing messages are
dispatched in the same order.  The server is trusted to break ties
when two members send a Commit message at the same time.