Re: [MLS] Key confirmation - Extra MAC needed?

[Russ Housley <[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 <https://github.com/mlswg/mls-protocol/pull/72>
> MAC: https://github.com/mlswg/mls-protocol/pull/71 <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.

The Derive approach is straightforward.  If this leaks in any surprising way, then draft-ietf-tls-exported-authenticator has a problem too, right?

Russ