Add explicit key confirmation

[bifurcation]

At the MLS interim, the major feedback regarding authentication was that it would be good practice to provide explicit key confirmation. This PR adds an explicit confirmation field to Handshake messages, containing a MAC over the proposed (updated) state of the group, together with the latest handshake message.

[jmillican]

Reflecting on offline conversation here:

This PR derives a new key, then calculates the MAC over both the HS message and the group state; that others verify. PR 72 derives a new key, then sends that to the others to verify they all got the same key. We assume that, as the key was derived from a tree with this group state, it must be correct.

These appear to test basically the same property, but I probably prefer this PR unless we can formally verify that they have the same properties (or at least the relevant ones); in which case 72 is a little more efficient.

[jmillican]

So one question would be under what circumstances would this verify something that won't be verified by failing AEAD on any associated messages that decrypt? Or is it more just that we've now decoupled updates and message sending, so without a failing AEAD we need this to confirm too?

[jmillican]

Agreed that we need further discussion with academics, and modelling of the properties, but this seems good to provisionally merge.

[bifurcation]

Thanks, @jmillican. Absolutely agree that this needs more discussion. I'll send a ping on the list shortly.

[bifurcation]

@jmillican To answer your question, yes, the idea here is to fail before you get to the AEAD stage. In the spec before this PR merged, group members that arrived at different states would have different keys, but they would never find out that was the case until there was an AEAD failure. With this PR (or #72), a peer know that if processing of a Handshake message succeeds, then it has the same GroupState as the sender.