Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule

[Brendan McMillion <[e-mail]>]

>
> Brendan: I think you might have the wrong premise in mind here.  The
> proposal we have been discussing would authenticate *both* that Alice is
> the sender of the message *and* that she's a member of the group.  So other
> members of the group could only impersonate Alice if they had compromised
> her signing key.
>

Sorry to change arguments, but I think you're right that I missed the
point. I actually don't think we should do anything here. That's because:
if Alice's long-term signing key is compromised, how can she be
impersonated? In all of these ways:

   1. An outsider can send a message to an existing group.
   2. An insider can send a message to an existing group.
   3. An attacker can generate new KeyPackages and intercept Welcome
   messages intended for her.
   4. An attacker can forge her existence in a group she's not in.

The PR you opened only addresses attack vector #1. You still have all the
other attack vectors and to address them, Alice needs to rotate her
long-term signing key. Rotating the long-term signing key should be the
resolution here, not heading off an individual attack.

In the past, we usually considered the long-term signing key to be stored
somewhere more secure than everything else, such that it was very unlikely
to be compromised, or that it was rotated regularly. That's why we haven't
worried about this in the past.

On Tue, Aug 18, 2020 at 12:21 PM Richard Barnes <[e-mail]> wrote:

> Brendan: I think you might have the wrong premise in mind here.  The
> proposal we have been discussing would authenticate *both* that Alice is
> the sender of the message *and* that she's a member of the group.  So other
> members of the group could only impersonate Alice if they had compromised
> her signing key.
>
>
> On Tue, Aug 18, 2020 at 12:35 PM Brendan McMillion <brendan=
> [e-mail] <[e-mail]>> wrote:
>
>> So to that end, how
>>> about we modify MLS such that MLSPlaintext packets coming from group
>>> members
>>> must also be authenticated using something from the application key
>>> schedule.
>>
>>
>> My objection to this is that Alice can still be impersonated by members
>> in the group, if we only have symmetric forward-secure authentication.
>>
>> There's been some discussion in the past about using forward-secure
>> signatures that might be worth looking into instead, which would fully
>> address this attack vector:
>> https://mailarchive.ietf.org/arch/msg/mls/o3fmIul_4s6STmnqmz514cjADpw/
>>
>>
>> On Tue, Aug 18, 2020 at 7:36 AM Joel Alwen <[e-mail]> wrote:
>>
>>> Hey everyone,
>>>
>>> Something thats been bugging Marta Mularczyk and Daniel Jost and me for
>>> a bit
>>> now is that handshake messages sent out as MLSPlaintext packets are only
>>> authenticated using signatures, but not using the group's key schedule.
>>> For
>>> non-members that makes sense but for group members that's weaker than
>>> need be.
>>>
>>> Suppose Alice is in a group using signing key pair (spk, ssk). I corrupt
>>> her to
>>> learn ssk. Now I loose access to her device again. Later she generates a
>>> fresh
>>> key package with her same spk but a new HPKE key for her leaf. She sends
>>> out and
>>> update proposal for her new key package and someone commits to the
>>> update.
>>>
>>> Expected result: she (and the group at large) has achieved PCS again.
>>>
>>> Actual result: using her stolen ssk I can still forge a new proposal's
>>> (sent as
>>> MLSPlaintext packets) coming from Alice. Some things I could do with
>>> this power:
>>>  - I can generate a new key package kp for Alice using her spk and some
>>> HPKE key
>>> she doesn't know. Then I forge an update proposal for Alice with kp. If
>>> it gets
>>> committed I've effectively kicked her out of the group.
>>>  - I could forge Add's and Remove's coming from Alice, so I could trick
>>> the
>>> group into thinking Alice is trying to Add my account to the group or
>>> remove
>>> some other group member.
>>>
>>> Lemme know if I've missed something here in that scenario...
>>>
>>>
>>> If I didn't miss anything and the attacks really work as advertised then
>>> IMO
>>> this is kinda weak sauce and worth avoiding if possible. So to that end,
>>> how
>>> about we modify MLS such that MLSPlaintext packets coming from group
>>> members
>>> must also be authenticated using something from the application key
>>> schedule.
>>> Now the above attacks fail. As soon as Alice's update is gets committed
>>> I no
>>> longer know the group's key schedule and so can't forged packet from
>>> Alice. More
>>> generally, this brings the PCS guarantees when using MLSPlaintexts
>>> frameing in
>>> line with what we're getting from MLSCiphertext packets.
>>>
>>> Any thoughts?
>>>
>>> - Joël
>>>
>>>
>>>
>>> PS. For concreteness, we could probably extend the current mechanism for
>>> getting
>>> concistancy (the confirmation_tag) to also provide symmetric key
>>> authentication.
>>> E.g. include most of the MLSPlaintext content into whats being tagged by
>>> confirmation_tag. That would cover the case of a commit packet and
>>> doesn't even
>>> grow the size of MLSPlaintext packets over the current design.
>>>
>>> For a proposal packet we could also have a confirmation_tag but this one
>>> is
>>> computed using the *current* epoch's confirmation_key and
>>> confirmed_transcript_hash.
>>>
>>> _______________________________________________
>>> MLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>>
>