Subject: [MLS] Virtual Interim minutes

From: Nick Sullivan <[email-masked]>
Date: Wed, 29 Jan 2020 13:38:34 -0800

MLSWG,

Draft minutes from the productive first virtual interim posted below. If
you find an issue, submit a PR to Github:
https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurring/01-29-2020.md

Nick & Sean

Attendees:
Joel Alwen, Richard Barnes, Raphael Robert, Britta Hale, Brendan McMillion,
Nick Sullivan

#247 - Welcome confirmation and key derivation
* Fixes bugs RLB found in the last draft while implementing
* OK to merge after rebase / conflict resolution

#246 - Bugfixes in ClientInitKey, Commit, and Welcome
* Derives the Welcome encryption key instead of generating fresh
* ... under the general theory about not requiring freshness when not
necessary
* OK to merge after rebase / conflict resolution

#283 - Use the same ratchet for Handshake and Application keys
* There's no point to FS for Proposals because clients have to cache the
plaintext anyway
* Given that, the "flat derivation" approach should be fine
* We should have separate keys per sender to it easier to avoid nonce
collisions
* RLB and RR to decide whether we should derive nonces on a hash ratchet or
just use a counter

#287 - Switch to signing strategy using one signature per leaf.
* There was agreement among those on the call to proceed with this strategy
(tree-hash-covers-parent-hash)
* ... given the deniability concerns and unclear benefit of the alternative
(parent-hash-covers-tree-hash)
* If further considerations come to light from analysis, we can revisit
later

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jan 2020 18:35:43 -0500

Couple of additional notes:

#247 - Welcome confirmation and key derivation
This turned out to be obsolete, so I just closed it.

#246 - Bugfixes in ClientInitKey, Commit, and Welcome
This was mostly obsolete, so I refactored it to fix one typo and add an
extension for an application-provided CIK ID.  Then merged.

#281 - Extend the epoch with a commit hash
Thanks in part to some vigorous discussion at the interim, I've gotten over
my ardor for forking and closed this PR :)  I still think it will be
desirable to be able to have nonlinear history, but I also think it
requires some further analysis, and can be done as an extension.

As Brendan noted on the call, #287 depends on #286 and #286, so we should
probably merge those first...

#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.

#286 - Editorial: Unclear that Commits always include an Update/refreshes
the CIK for the committer.
I think this is ready to merge, with one minor clarification.

If I don't hear objections by Monday, I'll go ahead and commit #285, #286,
and #287.

--Richard

On Wed, Jan 29, 2020 at 4:39 PM Nick Sullivan <nick=
[email-masked]> wrote:

> Joel Alwen, Richard Barnes, Raphael Robert, Britta Hale, Brendan
> McMillion, Nick Sullivan
>
> * RLB and RR to decide whether we should derive nonces on a hash ratchet
> or just use a counter
>
> * There was agreement among those on the call to proceed with this
> strategy (tree-hash-covers-parent-hash)
> * ... given the deniability concerns and unclear benefit of the
> alternative (parent-hash-covers-tree-hash)
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 30 Jan 2020 00:48:44 +0100

> 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.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Jan 2020 09:43:38 -0500

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

> 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