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

[Richard Barnes <[e-mail]>]

I'm not really grokking the PCS sig scheme, but it seems like it's (a) not
general to all signature schemes, and (b) complicated enough I would want
review from CFRG.  Both of which seem like deal breakers for being a
requirement here.

Much like SIV, it would be nice if we could support it as an option, but I
wouldn't want to require it.

On Tue, Aug 18, 2020 at 2:26 PM Joel Alwen <[e-mail]> wrote:

> Chaining key pairs builds a PCS sig scheme from a standard one. (No FS
> needed.)
>
> PCS sigs could be helpful as a complementary mechanism for getting yet
> more PCS auth. If so it seems worth it to think if we cant get a more
> efficient construction of PCS sigs.
>
> Regardless, proving to receivers that the author of a message knows the
> current group key schedule still seems prudent to me.
>
> - Joël.
>
> On Tue, 18 Aug 2020, 19:37 Brendan McMillion, <[e-mail]>
> wrote:
>
>> I actually describe in the thread I linked how to take a standard FS
>> signature and turn it into a PCS signature. While it's baked into the
>> primitive, essentially what's happening is that every time Alice sends an
>> Update, she generates a new signing key and certifies it with her old
>> signing key before discarding the old signing key. So if Alice's Update is
>> accepted by the group, anyone who compromised the old signing key can't
>> sign new messages because they don't have the private key of the *new*
>> signing key.
>>
>> On Tue, Aug 18, 2020 at 9:55 AM Joel Alwen <[e-mail]> wrote:
>>
>>> > My objection to this is that Alice can still be impersonated by
>>> members in the group, if we only have symmetric forward-secure
>>> authentication.
>>>
>>> I'm missing how FS sigs (or any other FS auth primitive) helps. My
>>> understanding
>>> is FS auth primitives prevent leaked keys from being used to authenticate
>>> messages in *past* time periods. But the attack involves signing
>>> messages for
>>> time periods (epochs) after the leak occurred not before the leak.
>>> Imagine we
>>> could deterministically ratchet sig key pairs forward much like we can
>>> MAC keys.
>>> We'd have an FS sig scheme but I dont see how this fixes the problem.
>>>
>>> Which is not to say that FS sigs dont solve an auth problem for MLS.
>>> Just,
>>> AFAIK, not this one. (Rather they help prevent forgeries in bygone
>>> epochs.)
>>>
>>> What I do agree with is that other group members (that know Alice's sig
>>> key) can
>>> still impersonate her in future epochs till she updates the key. The
>>> same is
>>> true when sending MLSCiphertexts.
>>>
>>> Unfortunately, for epochs between when Alice's state is leaked and when
>>> Alice
>>> finally updates her (authentication specific) asymmetric key material I
>>> see no
>>> way around this. It seems inherent to the adversarial model since other
>>> group
>>> member know and can do everything Alice can during those epochs.
>>>
>>> One thing we could look at are PCS signatures. Something like the
>>> Updateable PKE
>>> scheme in the RTreeKEM work. Namely every time you sign you also
>>> re-randomize
>>> your signing key (or simply sample new ones). That way leaking your old
>>> key
>>> doesnt let me sign under your re-randomized new key just like in UPKE
>>> leaking
>>> your old decryption key doesnt let me read ciphertexts encrypted to your
>>> re-randomized new key. Make sense?
>>>
>>>
>>> - Joël
>>>
>>>
>>> On 18/08/2020 18:34, Brendan McMillion 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]
>>> > <mailto:[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] <mailto:[e-mail]>
>>> >     https://www.ietf.org/mailman/listinfo/mls
>>> >
>>>
>> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>