Subject: [MLS] Overflow discussion on #406

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Oct 2020 14:53:59 -0400

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.

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.

--RLB

[1] https://github.com/cisco/mlspp/pull/118
[2] https://github.com/mlswg/mls-protocol/pull/428

---

From: Raphael Robert <[email-masked]>
Date: Wed, 21 Oct 2020 17:38:43 +0200

Thanks for writing this up, see my comments inline.

> On 20 Oct 2020, at 20:53, Richard Barnes <[email-masked]> 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 :)
> 
> 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.

> (This is more of an engineering question than a security question)  To summarize how the transcript hashes / confirmation tag work:
> 
> 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 <https://github.com/cisco/mlspp/pull/118>
> [2] https://github.com/mlswg/mls-protocol/pull/428 <https://github.com/mlswg/mls-protocol/pull/428>_______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Oct 2020 14:28:01 -0400

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 <[email-masked]> 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 :)
>
> 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.
>
>
> _______________________________________________
> MLS mailing list
> [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 26 Oct 2020 17:54:55 -0400

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 <[email-masked]> wrote:

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