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

["Katriel Cohn-Gordon" <[e-mail]>]

I wouldn't die on this hill, but I prefer the MAC design just for
cleanness reasons in analysis. Collapsing the final two MAC invocations
in the derivation doesn't seem like it gets you very much.
Note that we wouldn't have to MAC over the message transcript---over the
constant zero might be enough.
k


On Tue, 23 Oct 2018, at 4:08 PM, Richard Barnes wrote:
> 
> 
> On Tue, Oct 23, 2018 at 6:34 AM Russ Housley
> <[e-mail]> wrote:>> 
>>> 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.>> 
>> The Derive approach is straightforward.  If this leaks in any
>> surprising way, then draft-ietf-tls-exported-authenticator has a
>> problem too, right?> 
> I don't think that necessarily follows.  That draft follows the MAC
> approach, in that the values it exports from the TLS key schedule are
> used as inputs to a MAC, and only the MAC output is published.> 
> That said, I agree it's instructive to look at uses of the TLS
> exporter to identify parallel risks here.  You would want to find some
> case where an exported value is used as a public value.
> Unfortunately, the only other major usage of exporters that comes to
> mind is DTLS-SRTP, which exports a key and salt.  You could use that
> to argue either way, since the salt is notionally public, but in
> practice is never published.> 
> --Richard
> 
> _________________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls