Proof of prior membership in the group / Resumption

[bifurcation]

[This issue is part of a feature breakdown based on #336]

There are two cases where the members of a group might want to authenticate that the other members of the group were present at another point in history:

1. A user who has lost state re-joining the group
2. Re-initializing the group with different parameters
3. Initializing a subgroup from a master group

In the former case, the group would want to authenticate that the user re-joining is the same user who was present at some past point in the history of the group. In the latter two cases, the members of the new, re-initialized group would be authenticating that everyone in the new group was also in the old group.

These use cases are similar to resumption in TLS, where a PSK is derived from the key schedule and used as for authentication in a different session. A similar approach seems sensible here, roughly:

1. At each epoch of the group derive a PSK and PSK ID to be used
2. Use the general PSK signaling mechanism (Negotiate PSKs #367) to signal that a prior epoch's PSK should be used

This approach is also a good indication that the PSK mechanism in #367 should allow for PSKs to have specified types. In TLS, there has been some confusion about how applications can distinguish external PSKs from resumption PSKs. If we have an explicit type here, we won't end up with that confusion.

[kkohbrok]

As noted in my comment on #367, this is all detailed and implemented in PR #336.

We created #336 based on the use cases you identified and reached the same conclusions. Getting the PSK derivations and their inclusion in the key schedule right is a little tricky. How should we proceed? It probably makes sense to agree on something to merge for #367 and then create a separate PR for this issue with whatever is left of the original #336 PR.

[bifurcation]

Yeah, the idea of this sequence of issues (#366, #367, #368, #374) was to pull apart the multiple features being addressed in #336.

As you can see with #369 and #376, I've begun posting PRs to address these smaller issues, drawing on the work done in #336 and adding details / refinements that were missing. Would it be a sensible split to cover #366 and #367 with those, and update #336 to cover #368 and #374?

[bifurcation]

Fixed by #336