Change:
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.
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.
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?
Thanks, NAME Absolutely agree that this needs more discussion. I'll send a ping on the list shortly.
NAME 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 ), a peer know that if processing of a Handshake message succeeds, then it has the same GroupState as the sender.
Agreed that we need further discussion with academics, and modelling of the properties, but this seems good to provisionally merge.

Discussion:
Removed ART (*) <ins> Added explicit key confirmation (*) </ins> draft-01 Initial description of the Message Protection mechanism. (*)

Verify that the "prior_epoch" field of the Handshake message is equal the "epoch" field of the current GroupState object. <del> Use the "operation" message to produce an updated GroupState object incorporating the proposed changes. </del> <ins> Use the "operation" message to produce an updated, provisional GroupState object incorporating the proposed changes. </ins> Look up the public key for slot index "signer_index" from the roster in the current GroupState object (before the update).

If the signature fails to verify, discard the updated GroupState object and consider the Handshake message invalid. <del> If the signature verifies successfully, consider the updated </del> <ins> Use the "confirmation_key" for the new group state to compute the finished MAC for this message, as described below, and verify that it is the same as the "finished_mac" field. If the the above checks are successful, consider the updated </ins> GroupState object as the current state of the group. <ins> The "finished_mac" value is computed over the provisional group state and the current handshake message (with the confirmation value set to zero): HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. </ins> [[ OPEN ISSUE: The Add and Remove operations create a "double-join" situation, where a participants leaf key is also known to another participant.  When a participant A is double-joined to another B,