Re: [MLS] Overflow discussion on #406

[Richard Barnes <[e-mail]>]

It seems like the only outstanding question here is whether a signature is
required on GroupPublicState.  That seems like a straightforward addition
that we could handle during WGLC, between draft-10 and draft-11, before
feature freeze.  That way we can go ahead and start getting wider review
while we resolve these last issues.

Unless I hear an objection here before Monday US ET, I'll go ahead and
merge #406 and work on getting draft-10 out the door.

--Richard

On Wed, Oct 21, 2020 at 11:38 AM Raphael Robert <[e-mail]> wrote:

> Thanks for writing this up, see my comments inline.
>
> On 20 Oct 2020, at 20:53, Richard Barnes <[e-mail]> wrote:
>
> Our interim call went about 30min past our scheduled end time today.
> Since we were without chairs for the last 30min, that time was not official
> WG time, so we couldn't make decisions about PRs.  Luckily, we only had one
> PR remaining, and we couldn't come to agreement on it anyway :)
>
> Two remaining questions on PR#406, where the first is more important:
>
> 1. Should the GroupKeyPackage / GroupPublicState be signed?
>
> On the one hand, having a signature would remove any concerns about
> copy/paste recombination of the various constituent parts.  In particular,
> it would avoid the public key for one group being reused with another (up
> to reuse of signature keys across groups).
>
> On the other hand, Raphael expressed some concern about deniability, since
> this would be a public signature by a member of the group over the whole
> state of the group.
>
> Personally, signing seems like the conservative option to me.  But I
> haven't done much analysis here.
>
>
> Joel brought up a question regarding tree signatures yesterday, that he
> said he’d describe on this list shortly. I see a lot of overlap between
> these discussion and would like to wait for that discussion to unfold
> before jumping to conclusions here.
>
>
> 2. Which transcript hash(es) should be included?
>
> (This is more of an engineering question than a security question)  To
> summarize how the transcript hashes / confirmation tag work:
>
> confirmed = H(interim || all_of_commit_besides_confirmation_tag)
> confirmation_tag = MAC(confirmation_key, confirmed)
> interim = H(confirmed || confirmation_tag)
>
> In a GroupInfo / Welcome based join, the joiner needs the confirmed
> transcript hash but not the interim.  The confirmation tag is provided in
> the GroupInfo and verified by the joiner, and can then be used to compute
> the interim transcript hash.  (This is a side effect of #416, which moved
> the signature from interim to confirmed)  In other words, the joiner starts
> at the second line above, since they don't actually see the commit.
>
> In an GroupPublicState / Commit based join, the joiner is computing the
> commit, so they start at the first line.  As a result, the joiner needs the
> interim transcript hash, not the confirmed transcript hash.
>
> I have implemented these changes (removing interim from GroupInfo and
> confirmed from GroupPublicState) in my draft implementation of #406 [1],
> and they do work.  I have filed a small spec PR to remove this [2] and
> suggested the corresponding changes in #406.
>
>
> This looks fine to me, the hashes are now swapped in the PR.
>
> Raphael
>
>
> --RLB
>
> [1] https://github.com/cisco/mlspp/pull/118
> [2] https://github.com/mlswg/mls-protocol/pull/428
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>
>
>