Re: [MLS] Overflow discussion on #406

[Richard Barnes <[e-mail]>]

Hey all,

I didn't hear an objection, but Joël did point out a pretty significant
risk to me of not having a signature over at least the HPKE public key in
the GroupPublicState.  So I have merged #406 and posted #433 as a follow-up
to add a signature over the group ID, epoch, and HPKE public key.

https://github.com/mlswg/mls-protocol/pull/433

Please send any comments on that by Wednesday US ET.  If there are no
objections by then, I'll merge that, issue draft-10, and ask the chairs to
issue WGLC on draft-10.

While we're in WGLC, we have at least two issues to discuss:
1. Is the signature in #433 sufficient, or should it cover more of the
GroupPublicState?
2. How should we refactor the tree signing / parent hash scheme to address
the issues raised by Joël, Daniel, and Marta?

Cheers,
--Richard


On Fri, Oct 23, 2020 at 2:28 PM Richard Barnes <[e-mail]> wrote:

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