Subject: [MLS] Do we need confirmation_tag?

From: Richard Barnes <[email-masked]>
Date: Thu, 31 Mar 2022 10:34:47 -0400

Hi folks,

I was just implementing PR#529 in mlspp, which required some cleanup in
transcript handling, which got me looking at confirmation_tag.

It seems like we have two redundant values derived from the key schedule:

authentication_secret = DeriveSecret(epoch_secret, "authentication")
confirmation_tag = MAC(DeriveSecret(epoch_secret, "confirmation_key"),
GroupContext.confirmed_transcript_hash)

I say these values are redundant because the confirmed transcript hash is
already included in the derivation of the epoch_secret (via the inclusion
of the GroupContext).

Could we just use the authentication_secret (which is not really secret)
where we use confirmation_tag today?

When we originally defined the confirmation tag, the extra MAC was added so
that we wouldn't be publishing a value derived directly from the epoch
secret.  But (a) if HKDF works, that extra layer shouldn't be necessary,
and (b) we're already treating the authentication_secret as public (by
encouraging members to send it out of band).

If this idea sounds good to folks, I can make a short PR.

Thanks,
--Richard

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Thu, 31 Mar 2022 15:19:19 +0000

Deriving keys that cover similar context is not really the decision point consideration in this (the whole key schedule set is derived over similar context, after all). What is the decision point is how these keys will be used and if those uses overlap, or if crossing them can lead to vulnerabilities. For example, the encryption_secret and exporter_secret are also derived across similar context, but using just one key for both would be unwise.

Comparing uses:

  *   The authentication_secret is used for OOB authentication. As a correction to the claim, this does not imply that that use is or should be public though. That depends on the application. Much like an exporter_secret or any other, it depends on how the OOB authentication proceeds.
  *   The confirmation_key is used to compute the confirmation_tag which is used internally to MLS (MLSMessageAuth object).

These are very different uses, not least of all from the fact that the first is for use external to MLS and the second is for use internal to MLS. Again, doubling up on the use of these would not be unlike doubling up on the use of the (internal) encryption_secret and (external) exporter_secret. It opens up a graveyard of potential mis-implementations and vulnerabilities.

I have no current preference on whether to keep a MAC in the derivation of the confirmation_key. However, given the above I strongly press that we keep the keys and their uses separate.

-- Britta

From: MLS <[email-masked]> on behalf of Richard Barnes <[email-masked]>
Date: Thursday, March 31, 2022 at 7:35 AM
To: Messaging Layer Security WG <[email-masked]>
Subject: [MLS] Do we need confirmation_tag?

Hi folks,

I was just implementing PR#529 in mlspp, which required some cleanup in transcript handling, which got me looking at confirmation_tag.

authentication_secret = DeriveSecret(epoch_secret, "authentication")
confirmation_tag = MAC(DeriveSecret(epoch_secret, "confirmation_key"), GroupContext.confirmed_transcript_hash)

I say these values are redundant because the confirmed transcript hash is already included in the derivation of the epoch_secret (via the inclusion of the GroupContext).

Could we just use the authentication_secret (which is not really secret) where we use confirmation_tag today?

When we originally defined the confirmation tag, the extra MAC was added so that we wouldn't be publishing a value derived directly from the epoch secret.  But (a) if HKDF works, that extra layer shouldn't be necessary, and (b) we're already treating the authentication_secret as public (by encouraging members to send it out of band).

Thanks,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 31 Mar 2022 12:16:36 -0400

The uses actually don't seem that different to me.  Both in the Commit case
and in the external auth case, you're confirming that all parties have the
same state.  The usage in Commit makes sure that everyone in the group
agrees; the external usage makes sure that the verifying parties are in the
same group.

And to be clear, if the authentication_secret is to be used for OOB
authenticaiton, then it needs to be public at least in the sense that
revealing it to someone outside the group cannot undermine the security
properties of the group.  Unless you design your OOB authn protocol very
carefully, you're going to be exposing the authentication_secret to someone
whose membership in the group you have not yet authenticated, so you can't
be sure you're not exposing it outside the group.

--RLB

On Thu, Mar 31, 2022 at 11:19 AM Hale, Britta (CIV) <[email-masked]>
wrote:

> Deriving keys that cover similar context is not really the decision point
> consideration in this (the whole key schedule set is derived over similar
> context, after all). What is the decision point is how these keys will be
> used and if those uses overlap, or if crossing them can lead to
> vulnerabilities. For example, the encryption_secret and exporter_secret are
> also derived across similar context, but using just one key for both would
> be unwise.
>
>
>
> Comparing uses:
>
>    - The authentication_secret is used for OOB authentication. As a
>    correction to the claim, this does not imply that that use is or should be
>    public though. That depends on the application. Much like an
>    exporter_secret or any other, it depends on how the OOB authentication
>    proceeds.
>    - The confirmation_key is used to compute the confirmation_tag which
>    is used internally to MLS (MLSMessageAuth object).
>
>
>
> These are very different uses, not least of all from the fact that the
> first is for use external to MLS and the second is for use internal to MLS.
> Again, doubling up on the use of these would not be unlike doubling up on
> the use of the (internal) encryption_secret and (external) exporter_secret.
> It opens up a graveyard of potential mis-implementations and
> vulnerabilities.
>
>
>
> I have no current preference on whether to keep a MAC in the derivation of
> the confirmation_key. However, given the above I strongly press that we
> keep the keys and their uses separate.
>
>
>
> -- Britta
>
>
>
>
>
> *From: *MLS <[email-masked]> on behalf of Richard Barnes <[email-masked]
> >
> *Date: *Thursday, March 31, 2022 at 7:35 AM
> *To: *Messaging Layer Security WG <[email-masked]>
> *Subject: *[MLS] Do we need confirmation_tag?
>
>
>
>
>
> Hi folks,
>
>
>
> When we originally defined the confirmation tag, the extra MAC was added
> so that we wouldn't be publishing a value derived directly from the epoch

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Thu, 31 Mar 2022 17:16:48 +0000

Authenticity confirmation, as a concept, is the same in both cases – but the uses are different. The confirmation_secret is internal to MLS and for a specified use, while the authentication_secret is external and for an unspecified use. Key reuse is a poor design choice regardless of application and it is a very basic premise to avoid it.

Added to that, the specified/unspecified aspects of those uses inherently mean that there may be a threat model aspect different on each that is not currently known and could lead to vulnerabilities. Since the unspecified uses are out-of-scope of the protocol definition, we should be even more careful about key reuse (in addition to the basic no-go for such a design choice).

-- Britta

From: Richard Barnes <[email-masked]>
Date: Thursday, March 31, 2022 at 9:16 AM
To: "Hale, Britta (CIV)" <[email-masked]>
Cc: Messaging Layer Security WG <[email-masked]>
Subject: Re: [MLS] Do we need confirmation_tag?

The uses actually don't seem that different to me.  Both in the Commit case and in the external auth case, you're confirming that all parties have the same state.  The usage in Commit makes sure that everyone in the group agrees; the external usage makes sure that the verifying parties are in the same group.

And to be clear, if the authentication_secret is to be used for OOB authenticaiton, then it needs to be public at least in the sense that revealing it to someone outside the group cannot undermine the security properties of the group.  Unless you design your OOB authn protocol very carefully, you're going to be exposing the authentication_secret to someone whose membership in the group you have not yet authenticated, so you can't be sure you're not exposing it outside the group.

--RLB

On Thu, Mar 31, 2022 at 11:19 AM Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:
Deriving keys that cover similar context is not really the decision point consideration in this (the whole key schedule set is derived over similar context, after all). What is the decision point is how these keys will be used and if those uses overlap, or if crossing them can lead to vulnerabilities. For example, the encryption_secret and exporter_secret are also derived across similar context, but using just one key for both would be unwise.

Comparing uses:

-- Britta

From: MLS <[email-masked]<mailto:[email-masked]>> on behalf of Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 31, 2022 at 7:35 AM
To: Messaging Layer Security WG <[email-masked]<mailto:[email-masked]>>
Subject: [MLS] Do we need confirmation_tag?

Hi folks,

Thanks,
--Richard

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 31 Mar 2022 19:28:52 -0700

Britta said:
>Since the unspecified uses are out-of-scope of the protocol definition, we
should be even more careful about key reuse (in addition to the basic no-go
for such a  design choice).

I find that to be a pretty compelling reason to leave them separate.
Thanks,
-r

*Rohan Mahy  *l  Vice President Engineering, Architecture

Chat: @rohan_wire on Wire

Wire <https://wire.com/en/download/> - Secure team messaging.

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
Berlin,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>

Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675

On Thu, Mar 31, 2022 at 10:17 AM Hale, Britta (CIV) <[email-masked]>
wrote:

> Authenticity confirmation, as a concept, is the same in both cases – but
> the uses are different. The confirmation_secret is internal to MLS and for
> a specified use, while the authentication_secret is external and for an
> unspecified use. Key reuse is a poor design choice regardless of
> application and it is a very basic premise to avoid it.
>
>
>
> Added to that, the specified/unspecified aspects of those uses inherently
> mean that there may be a threat model aspect different on each that is not
> currently known and could lead to vulnerabilities. Since the unspecified
> uses are out-of-scope of the protocol definition, we should be even more
> careful about key reuse (in addition to the basic no-go for such a design
> choice).
>
>
>
> -- Britta
>
>
>
>
>
> *From: *Richard Barnes <[email-masked]>
> *Date: *Thursday, March 31, 2022 at 9:16 AM
> *To: *"Hale, Britta (CIV)" <[email-masked]>
> *Cc: *Messaging Layer Security WG <[email-masked]>
> *Subject: *Re: [MLS] Do we need confirmation_tag?
>
>
>
> The uses actually don't seem that different to me.  Both in the Commit
> case and in the external auth case, you're confirming that all parties have
> the same state.  The usage in Commit makes sure that everyone in the group
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>