Re: [MLS] Virtual Interim minutes

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=
40cloudflare.com@dmarc.ietf.org> wrote:

> 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
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>