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

[Richard Barnes <[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.


On Tue, Aug 18, 2020 at 12:35 PM Brendan McMillion <brendan=
[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
>