[MLS] Key confirmation - Extra MAC needed?

[Richard Barnes <[e-mail]>]

Hey all,

In the just-released -02 draft of MLS, I've added a key confirmation step
to the handshake authentication process.  Important question after "====="
below...

In the previous draft, there was an authentication mechanism that ensured
that if two group members ended up with different GroupState objects, then
they would have different keys.  However, it did not provide any way for
group members to recognize that this was the case, except for AEAD checks
on encrypted messages failing.  With explicit key confirmation, the
recipient of a Handshake message knows that if processing of the handshake
message succeeds, then the recipient has the same GroupState as the sender.

This provides a degree of protection against malicious insiders that send
different TreeKEM values to different parts of the tree.  Namely, only the
subset of the tree that got the key matching the key confirmation will
accept the Handshake message; the others will be locked out. (Assuming a
broadcast channel; if the sender can send different key confirmations to
different recipients, then this is no help.). This isn't complete
protection, but at least the locked-out members know they've been locked
out, and can complain about it.

=====

The major question here is whether it's sufficient to derive a key
confirmation value from the key schedule and publish it, or whether the
value derived in the key schedule should be used as a MAC key to generate a
MAC over the message transcript.   I've posted PRs for both; the latter is
what I merged in -02

Derive: https://github.com/mlswg/mls-protocol/pull/72
MAC: https://github.com/mlswg/mls-protocol/pull/71

On the one hand, the MAC-based approach is what is done in TLS.  It feels
safer, because we never publish anything that's in the key schedule diagram.

On the other hand, the Derive-Secret operation used to create the key
confirmation value in the key schedule is **already** based on HMAC.  So it
doesn't seem like the extra MAC step is adding that much value.

If we can convince ourselves that the Derive approach (without the extra
MAC) is sufficient, I would prefer to do that, since it's simpler.  But
feedback on this point would be very much appreciated.

--Richard