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

[Brendan McMillion <[e-mail]>]

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
> >
>