Remove confirmation_tag from transcript

[bifurcation]

On the one hand: It would simplify the transcript hash a fair bit if we omitted the confirmation_tag from the transcript. We could get rid of the notion of the interim transcript hash. It doesn’t seem like there’s much security being added by its inclusion, since it’s determined by what came before. In other words, including the confirmation tag in the transcript only serves to feed it into the next epoch secret, but the confirmation tag just summarizes the previous transcript and epoch secret, which are already fed into the next epoch secret via the init_secret.

On the other hand: The analogous value in TLS is the Finished messages, which are included in the transcript.

We should obviously only do this if supported by updated proofs. @TWal ?

[br-hale]

Tagging @kkohbrok as we were just discussing this and how the confirmation_tag basically commits to more of the tree structure than just the rolling key derivation. I will take another look at this.

[kkohbrok]

I can't speak to the proofs, but one nice thing about including the confirmation tag in the transcript is that the transcript is a continuous aggregation of messages. As you point out @bifurcation the key schedule also indirectly includes all past messages, so I'm not overly concerned, but it generally means that the group context does not contain the "history" of the group anymore. So to get a value that really includes the group's history, we'd have to use an exporter, where previously, we could have just used the group context. Again, not sure this is a huge concern.

On another note: After all the cryptographic analysis that MLS has seen in the past, I find it a bit concerning that in the last minute, we're still tinkering with the cryptographic design. Intuitively, I don't think this proposed change, or the one to the membership tag computation are a problem, but I'd rather have a proof to back up that intuition. The way I understand the IETF release process, the next peer-review cryptographic proof that includes all the changes we make now is in all likelihood going to be released quite some time after the RFC itself.

[mulmarta]

Adding my 2 cents, similar @kkohbrok I'm a bit hesitant about changing the cryptographic design at this point. I would feel much more confident leaving it as is.

This being said, I think that removing the tag from the transcript should be secure. In fact, our security proof relies on the fact that agreement on the interim hash implies agreement on the confirmed hash. (This holds exactly for the reasons given by @bifurcation.) In other words, the tag is already indirectly included in the interim hash.

As a side note, if there could be many acceptable tags for 1 commit, the protocol may behave strangely. For instance, say we have a commit C with 2 possible acceptable confirmation tags T1 and T2. Say Alice accepts C with T1 and Bob accepts C with T2. They agree on the interim hash, so they have the same key schedule and can exchange application messages. However, they disagree on the confirmed hash so they will never accept commits from each other.

[bifurcation]

Virtual interim 2022-05-19:

• Consensus that the simplification isn't worth the change at this point