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

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2018 10:33:22 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Oct 2018 09:33:58 -0400

> 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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 23 Oct 2018 08:08:06 -0700

On Tue, Oct 23, 2018 at 6:34 AM Russ Housley <[email-masked]> wrote:

> 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

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Tue, 23 Oct 2018 16:12:57 +0100

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
> <[email-masked]> 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.>>> 
>>> =====
>>> 
>>> 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>>> 
>>> 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?> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Tue, 23 Oct 2018 08:14:30 -0700

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

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

> cleanness reasons in analysis. Collapsing the final two MAC invocations in
> the derivation doesn't seem like it gets you very much.
>
> on encrypted messages failing..  With explicit key confirmation, the
> *_______________________________________________*
> MLS mailing list
> [email-masked]
> _______________________________________________
> MLS mailing list
> [email-masked]

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Tue, 23 Oct 2018 16:22:26 +0100

"Publish a MAC with a secret key" seems like a safe-ish operation
in general.
"Publish a secret key from the key schedule" seems like a dangerous
operation in general.
The fact that the key schedule happens to derive keys in a sensible
enough way that publishing one key doesn't affect security of the others
is a very good feature, but in my head it seems a bit funny to conclude
that it's safe to publish keys. IOW, the cleanness I am thinking of is
the separation between how the key schedule works and what the protocol
does with the derived keys.
k