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

[Richard Barnes <[e-mail]>]

Can you say more about how MAC'ing over "" makes things cleaner?

On Tue, Oct 23, 2018 at 8:13 AM Katriel Cohn-Gordon <[e-mail]>
wrote:

> 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
>
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>