Subject: Re: [MLS] Do we need confirmation_tag?

From: Richard Barnes <[email-masked]>
Date: Fri, 1 Apr 2022 10:07:04 -0400

I think that might be slightly more conservative than necessary, but it's a
fair point that since the authentication_secret is being exported, we don't
know what people will do with it.  I can live with leaving things separate.

Maybe we should still remove the extra MAC, though.  Just something like:

authentication_secret = DeriveSecret(epoch_secret, "authentication")
confirmation_tag = DeriveSecret(epoch_secret, "confirmation")

On Thu, Mar 31, 2022 at 10:29 PM Rohan Mahy <[email-masked]> wrote:

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

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Fri, 1 Apr 2022 14:51:47 +0000

Concur on removing the MAC if for the confirmation_key.
A DeriveSecret calculation on those inputs should not be used to replace computation of the confirmation_tag though.

From: Richard Barnes <[email-masked]>
Date: Friday, April 1, 2022 at 7:07 AM
To: Rohan Mahy <[email-masked]>
Cc: "Hale, Britta (CIV)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MLS] Do we need confirmation_tag?

I think that might be slightly more conservative than necessary, but it's a fair point that since the authentication_secret is being exported, we don't know what people will do with it.  I can live with leaving things separate.

On Thu, Mar 31, 2022 at 10:29 PM Rohan Mahy <[email-masked]<mailto:[email-masked]>> wrote:
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).

Rohan Mahy  l  Vice President Engineering, Architecture
Chat: @rohan_wire on Wire

Wire<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwire.com%2Fen%2Fdownload%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=A9r%2FK8P7P9uE2tpO4xBEddOPvzGUo4uPCHBQwL5gfxI%3D&reserved=0> - Secure team messaging.
Zeta Project Germany GmbH  l  Rosenthaler Straße 40, <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0QjcrQ4BDkjqM%2BFWMVg4MRjA5i6S%2FUFFOW6OwgdM0Mk%3D&reserved=0> 10178 Berlin, <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0QjcrQ4BDkjqM%2BFWMVg4MRjA5i6S%2FUFFOW6OwgdM0Mk%3D&reserved=0> Germany<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0QjcrQ4BDkjqM%2BFWMVg4MRjA5i6S%2FUFFOW6OwgdM0Mk%3D&reserved=0>
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]<mailto:[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]<mailto:[email-masked]>>
Date: Thursday, March 31, 2022 at 9:16 AM
To: "Hale, Britta (CIV)" <[email-masked]<mailto:[email-masked]>>
Cc: Messaging Layer Security WG <[email-masked]<mailto:[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:

  *   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]<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,

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
_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mls<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmls&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PJT%2FgO3stoIBktOPjTjbTI9whTRfHwQ78rJcoh%2FCkmg%3D&reserved=0>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 1 Apr 2022 10:57:44 -0400

I think we are not concurring then :)  What I was proposing is to derive
the confirmation_tag directly from the key schedule, as opposed to
computing it as a MAC over the transcript hash:

BEFORE:
confirmation_key = DeriveSecret(epoch_secret, "confirmation_key")
confirmation_tag = MAC(confirmation_key,
GroupContext.confirmed_transcript_hash)

AFTER:
confirmation_tag = DeriveSecret(epoch_secret, "confirmation_key")

The theory being that the confirmed transcript hash is already input to the
epoch_secret, so MAC'ing it again doesn't add any value.

Does that seem problematic?

On Fri, Apr 1, 2022 at 10:51 AM Hale, Britta (CIV) <[email-masked]>
wrote:

> A DeriveSecret calculation on those inputs should not be used to replace
> computation of the confirmation_tag though.
>
>
>
>
>
> *Date: *Friday, April 1, 2022 at 7:07 AM
> *To: *Rohan Mahy <[email-masked]>
> *Cc: *"Hale, Britta (CIV)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> I think that might be slightly more conservative than necessary, but it's
> a fair point that since the authentication_secret is being exported, we
> don't know what people will do with it.  I can live with leaving things
> separate.
>
>
>
> Wire
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwire.com%2Fen%2Fdownload%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=A9r%2FK8P7P9uE2tpO4xBEddOPvzGUo4uPCHBQwL5gfxI%3D&reserved=0> -
> Secure team messaging.
>
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0QjcrQ4BDkjqM%2BFWMVg4MRjA5i6S%2FUFFOW6OwgdM0Mk%3D&reserved=0>10178
> Berlin,
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0QjcrQ4BDkjqM%2BFWMVg4MRjA5i6S%2FUFFOW6OwgdM0Mk%3D&reserved=0>
> Germany
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0QjcrQ4BDkjqM%2BFWMVg4MRjA5i6S%2FUFFOW6OwgdM0Mk%3D&reserved=0>
>
> 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
> *From: *MLS <[email-masked]> on behalf of Richard Barnes <[email-masked]
> >
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmls&data=04%7C01%7Cbritta.hale%40nps.edu%7C5dba8c079b354a89c90f08da13e8edce%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844188396591128%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PJT%2FgO3stoIBktOPjTjbTI9whTRfHwQ78rJcoh%2FCkmg%3D&reserved=0>
>
>

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Fri, 1 Apr 2022 15:30:06 +0000

An interesting proposal.

Intuitively, this would seem to be more efficient and cover all the needed content. It may cause some unexpected twists in provable security though.

You see, the transcript hash is then embedded in the DeriveSecret key (first input) vs. in the content being authenticated (second input on the MAC). The DeriveSecret/expand step is an HMAC, so at the core of this proposed change is how security is effected if you embed the data to be authenticated (the transcript hash) in a MAC function key vs in a MAC function data field.

A MAC is analyzed for forgery/collision/etc. over the second input, not the first in general. Ergo it depends on the security properties needed from the confirmation_tag. If the confirmation tag needs to be indistinguishable from random, then you get that with the proposed change. That does not automatically mean that you get EUF-CMA security over the transcript hash, collision resistance, or any other authentication property.

Consequently, while at an intuitive level the change appears to cover the requisite information, the actual security implications on it and what can or cannot be proven is a more subtle analysis. For a change like this, I think we would need WG discussion from everyone who has done analysis specifically covering that corner of MLS and what properties on the confirmation_tag were used in the proofs.

(Aside, GroupContext.confirmed_transcript_hash only appears once in the spec, and all other references use confirmed_transcript_hash, so that needs a fix regardless.)

From: Richard Barnes <[email-masked]>
Date: Friday, April 1, 2022 at 7:58 AM
To: "Hale, Britta (CIV)" <[email-masked]>
Cc: Rohan Mahy <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MLS] Do we need confirmation_tag?

I think we are not concurring then :)  What I was proposing is to derive the confirmation_tag directly from the key schedule, as opposed to computing it as a MAC over the transcript hash:

BEFORE:
confirmation_key = DeriveSecret(epoch_secret, "confirmation_key")
confirmation_tag = MAC(confirmation_key, GroupContext.confirmed_transcript_hash)

AFTER:

The theory being that the confirmed transcript hash is already input to the epoch_secret, so MAC'ing it again doesn't add any value.

On Fri, Apr 1, 2022 at 10:51 AM Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:
Concur on removing the MAC if for the confirmation_key.
A DeriveSecret calculation on those inputs should not be used to replace computation of the confirmation_tag though.

From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 1, 2022 at 7:07 AM
To: Rohan Mahy <[email-masked]<mailto:[email-masked]>>
Cc: "Hale, Britta (CIV)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MLS] Do we need confirmation_tag?

Wire<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwire.com%2Fen%2Fdownload%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DZFBQ6i7ZuysEp1nV2Gf8HlpQJXfo%2FDFiDEh3YkUloI%3D&reserved=0> - Secure team messaging.
Zeta Project Germany GmbH  l  Rosenthaler Straße 40, <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0> 10178 Berlin, <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0> Germany<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0>
Geschäftsführer/Managing Director: Morten J. Broegger
HRB 149847 beim Handelsregister Charlottenburg, Berlin
VAT-ID DE288748675

-- Britta

--RLB

Comparing uses:

-- Britta

Hi folks,

Thanks,
--Richard
_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mls<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmls&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OG4698IOPHYr5XIh%2BtZSP9zKMOHwIrAV307YYYKqPsg%3D&reserved=0>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Mon, 4 Apr 2022 11:18:16 +0200

Even though this seems sound at first sight, I generally agree with Britta that this requires further analysis.

To solve this, it looks like we could either
1. add a significant delay before we issue the standard for studying this specific change
2. we include that simplification in the next version of the protocol.

Personally, I am fine with keeping this safety net for the current version of the protocol and including that change in a next iteration.

Benjamin

> On 1 Apr 2022, at 17:30, Hale, Britta (CIV) <[email-masked]> wrote:
> 
> An interesting proposal. 
>  
> On Fri, Apr 1, 2022 at 10:51 AM Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
>> From: Richard Barnes <[email-masked] <mailto:[email-masked]>>
>> To: Rohan Mahy <[email-masked] <mailto:[email-masked]>>
>> Cc: "Hale, Britta (CIV)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Thu, Mar 31, 2022 at 10:29 PM Rohan Mahy <[email-masked] <mailto:[email-masked]>> wrote:
>>> Britta said:
>>> Wire <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwire.com%2Fen%2Fdownload%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DZFBQ6i7ZuysEp1nV2Gf8HlpQJXfo%2FDFiDEh3YkUloI%3D&reserved=0> - Secure team messaging.
>>> Zeta Project Germany GmbH  l  Rosenthaler Straße 40,  <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0>10178 Berlin,  <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0>Germany <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0>
>>> On Thu, Mar 31, 2022 at 10:17 AM Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
>>>> From: Richard Barnes <[email-masked] <mailto:[email-masked]>>
>>>> To: "Hale, Britta (CIV)" <[email-masked] <mailto:[email-masked]>>
>>>> Cc: Messaging Layer Security WG <[email-masked] <mailto:[email-masked]>>
>>>> On Thu, Mar 31, 2022 at 11:19 AM Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 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).
>>>>>  
>>>>> From: MLS <[email-masked] <mailto:[email-masked]>> on behalf of Richard Barnes <[email-masked] <mailto:[email-masked]>>
>>>>> To: Messaging Layer Security WG <[email-masked] <mailto:[email-masked]>>
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/mls <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmls&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OG4698IOPHYr5XIh%2BtZSP9zKMOHwIrAV307YYYKqPsg%3D&reserved=0>_______________________________________________
> MLS mailing list
> [email-masked]

---

From: Konrad Kohbrok <[email-masked]>
Date: Mon, 4 Apr 2022 12:52:35 +0200

While I agree that we should be careful with such changes this late in 
the process, I think this is a good opportunity to simplify the protocol 
a little.

It's not clear to me why we need a MAC here in the first place. If I'm 
not missing anything, deriving a secret for comparison is the more 
elegant solution, which is probably why we're doing it in case of the 
authentication_secret to begin with, although that key could of course 
be used in some other way.

Regarding authentication secret vs. confirmation secret: I'm not sure 
what the envisioned use for the authentication secret is. I always 
thought it was really only for comparison rather than for any potential 
use outside of the protocol. Indeed if the specified use is completely 
arbitrary and requires some sort of additional agreed-upon protocol, 
wouldn't it make more sense to have that protocol derive a key from the 
exporter for that purpose? In fact if we aren't more strict in 
specifying what the authentication secret can or can't be used for, 
outside applications have to do another derivation step anyway to avoid 
cross-protocol attacks.

This would allow us to unify the authentication and confirmation secret, 
which would then be considered public and available to the application 
layer, but explicitly for comparison only and _not_ for use in any other 
primitive/protocol.

Cheers,
Konrad

Am 04.04.22 um 11:18 schrieb Benjamin Beurdouche:
> Even though this seems sound at first sight, I generally agree with 
> Britta that this requires further analysis.
> 
> Personally, I am fine with keeping this safety net for the current 
> version of the protocol and including that change in a next iteration.
> 
> Benjamin
> 
>> On 1 Apr 2022, at 17:30, Hale, Britta (CIV) <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> An interesting proposal.
>> Intuitively, this would seem to be more efficient and cover all the 
>> needed content. It may cause some unexpected twists in provable 
>> security though.
>> You see, the transcript hash is then embedded in the DeriveSecret key 
>> (first input) vs. in the content being authenticated (second input on 
>> the MAC). The DeriveSecret/expand step is an HMAC, so at the core of 
>> this proposed change is how security is effected if you embed the data 
>> to be authenticated (the transcript hash) in a MAC function key vs in 
>> a MAC function data field.
>> A MAC is analyzed for forgery/collision/etc. over the second input, 
>> not the first in general. Ergo it depends on the security properties 
>> needed from the confirmation_tag. If the confirmation tag needs to be 
>> indistinguishable from random, then you get that with the proposed 
>> change. That does not automatically mean that you get EUF-CMA security 
>> over the transcript hash, collision resistance, or any other 
>> authentication property.
>> Consequently, while at an intuitive level the change appears to cover 
>> the requisite information, the actual security implications on it and 
>> what can or cannot be proven is a more subtle analysis. For a change 
>> like this, I think we would need WG discussion from everyone who has 
>> done analysis specifically covering that corner of MLS and what 
>> properties on the confirmation_tag were used in the proofs.
>> (Aside, GroupContext.confirmed_transcript_hash only appears once in 
>> the spec, and all other references use confirmed_transcript_hash, so 
>> that needs a fix regardless.)
>> *From:*Richard Barnes <[email-masked] <mailto:[email-masked]>>
>> *Date:*Friday, April 1, 2022 at 7:58 AM
>> *To:*"Hale, Britta (CIV)" <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:*Rohan Mahy <[email-masked] <mailto:[email-masked]>>, 
>> "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> *Subject:*Re: [MLS] Do we need confirmation_tag?
>> I think we are not concurring then :)  What I was proposing is to 
>> derive the confirmation_tag directly from the key schedule, as opposed 
>> to computing it as a MAC over the transcript hash:
>> BEFORE:
>> The theory being that the confirmed transcript hash is already input 
>> to the epoch_secret, so MAC'ing it again doesn't add any value.
>> On Fri, Apr 1, 2022 at 10:51 AM Hale, Britta (CIV) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> A DeriveSecret calculation on those inputs should not be used to 
>>> replace computation of the confirmation_tag though.
>>> *From:*Richard Barnes <[email-masked] <mailto:[email-masked]>>
>>> *Date:*Friday, April 1, 2022 at 7:07 AM
>>> *To:*Rohan Mahy <[email-masked] <mailto:[email-masked]>>
>>> *Cc:*"Hale, Britta (CIV)" <[email-masked] 
>>> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
>>> <[email-masked] <mailto:[email-masked]>>
>>> *Subject:*Re: [MLS] Do we need confirmation_tag?
>>> I think that might be slightly more conservative than necessary, but 
>>> it's a fair point that since the authentication_secret is being 
>>> exported, we don't know what people will do with it.  I can live with 
>>> leaving things separate.
>>>> >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).
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwire.com%2Fen%2Fdownload%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DZFBQ6i7ZuysEp1nV2Gf8HlpQJXfo%2FDFiDEh3YkUloI%3D&reserved=0> - 
>>>> Secure team messaging.
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0>10178 
>>>> Berlin, 
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0>Germany 
>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3DRosenthaler%2BStra%25C3%259Fe%2B40%2C%25C2%25A0%2B10178%2BBerlin%2C%25C2%25A0%2BGermany%26entry%3Dgmail%26source%3Dg&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gf6NOKBGYLhhDmGN0QQ9uwmSJ2wDjCnH2c%2F8aH8cyIY%3D&reserved=0>
>>>> On Thu, Mar 31, 2022 at 10:17 AM Hale, Britta (CIV) 
>>>> <[email-masked] <mailto:[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] <mailto:[email-masked]>>
>>>>> *Date:*Thursday, March 31, 2022 at 9:16 AM
>>>>> *To:*"Hale, Britta (CIV)" <[email-masked] 
>>>>> <mailto:[email-masked]>>
>>>>> *Cc:*Messaging Layer Security WG <[email-masked] <mailto:[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.
>>>>> 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:
>>>>>>
>>>>>>   * 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] <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,
>>>>>> I was just implementing PR#529 in mlspp, which required some 
>>>>>> cleanup in transcript handling, which got me looking at 
>>>>>> confirmation_tag.
>>>>>> 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).
>>>>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmls&data=04%7C01%7Cbritta.hale%40nps.edu%7C387117c7b6864dd4b90908da13f00133%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637844218851159824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OG4698IOPHYr5XIh%2BtZSP9zKMOHwIrAV307YYYKqPsg%3D&reserved=0>
>> <https://www.ietf.org/mailman/listinfo/mls>
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Apr 2022 10:02:14 -0400

Fair enough.  I'm OK letting this drop.
--RLB

On Mon, Apr 4, 2022 at 5:18 AM Benjamin Beurdouche <
[email-masked]> wrote:

> Personally, I am fine with keeping this safety net for the current version
> of the protocol and including that change in a next iteration.
>
> Benjamin
>
> Intuitively, this would seem to be more efficient and cover all the needed
> content. It may cause some unexpected twists in provable security though.
>
> (first input) vs. in the content being authenticated (second input on the
> MAC). The DeriveSecret/expand step is an HMAC, so at the core of this
> proposed change is how security is effected if you embed the data to be
> authenticated (the transcript hash) in a MAC function key vs in a MAC
> function data field.
>
> A MAC is analyzed for forgery/collision/etc. over the second input, not
> the first in general. Ergo it depends on the security properties needed
> from the confirmation_tag. If the confirmation tag needs to be
> indistinguishable from random, then you get that with the proposed change.
> That does not automatically mean that you get EUF-CMA security over the
> transcript hash, collision resistance, or any other authentication property.
>
> Consequently, while at an intuitive level the change appears to cover the
> requisite information, the actual security implications on it and what can
> or cannot be proven is a more subtle analysis. For a change like this, I
> think we would need WG discussion from everyone who has done analysis
> specifically covering that corner of MLS and what properties on the
> confirmation_tag were used in the proofs.
>
>
> (Aside, GroupContext.confirmed_transcript_hash only appears once in the
> spec, and all other references use confirmed_transcript_hash, so that needs
> a fix regardless.)
>
>
>
> *Date: *Friday, April 1, 2022 at 7:58 AM
> *Cc: *Rohan Mahy <[email-masked]>, "[email-masked]" <[email-masked]>
> The theory being that the confirmed transcript hash is already input to
> the epoch_secret, so MAC'ing it again doesn't add any value.
>