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

From: Joel Alwen <[email-masked]>
Date: Tue, 18 Aug 2020 16:36:15 +0200

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.

---

From: Raphael Robert <[email-masked]>
Date: Tue, 18 Aug 2020 16:55:34 +0200

Hi Joel,

For context: this would only apply when applications use cleartext MLSPlaintext for HS messages. The recommendation is still to encrypt them and send them around as MLSCiphertext.
That being said, we said we would like to support scenarios where HS messages are not necessarily encrypted.

Question: would this attack work with Commit messages? I’m thinking that they would be rejected because the attacker cannot compute the confirmation_tag.

As you mention in the PS, the easy target would be Proposal messages.

I’d be interested to see what exactly you would propose as a mitigation mechanism.

Raphael

> On 18 Aug 2020, at 16:36, Joel Alwen <[email-masked]> wrote:
> 
> Hey everyone,
> 
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Tue, 18 Aug 2020 15:15:53 +0000

Good catch Joël,

This is indeed very problematic against the PCS security goals.

If the motivation behind this is to provide a cleartext alternative to encrypted HS messages, then a regular message authentication code based on the current group context (to replace the encryption step) would be a simple solution. That binds a level of authentication to the group state while allowing messages to be in the clear if required.

Britta

On 8/18/20, 7:55 AM, "MLS on behalf of Raphael Robert" <[email-masked] on behalf of raphael=[email-masked]> wrote:

    NPS WARNING: *external sender* verify before acting.

    Hi Joel,

    

    Raphael

---

From: Joel Alwen <[email-masked]>
Date: Tue, 18 Aug 2020 17:16:45 +0200

> For context: this would only apply when applications use cleartext
MLSPlaintext for HS messages. The recommendation is still to encrypt them and
send them around as MLSCiphertext.

Yup, all this only applies for that case.

> Question: would this attack work with Commit messages? I’m thinking that they
would be rejected because the attacker cannot compute the confirmation_tag.

TBH for commit messages I haven't thought it through yet. (The attack on
Proposals looked like enough of an issue that we might wanna do something
already.) But on further thought we might be OK already for commit msgs. The
confirmation_tag is, in particular, also a MAC of the MLSPlaintext packet's
content as that's part of the confirmed_transcript_hash. That really doesn't
leave any room to reuse Alice's confirmation_tag values to forge a non-trivial
commit on her behalf. So a non-trivial forgery requires computing fresh tag
values but that won't work with out the symmetric key schedule which was the goal.

> As you mention in the PS, the easy target would be Proposal messages.

Indeed. As far as I can tell those simply having nothing at all that depends on
the symmetric key schedule.

> I’d be interested to see what exactly you would propose as a mitigation mechanism.

Given that Commit's seem ok as is, how about adding an opaque tag<0...255> to
MLSPlaintext struct if and only if content_type == proposal && sender_type ==
member. In that case we set tag := KDF.Extract(confirmation_key,
MLSPlaintextTBS). (Here, conf key is taken from the current epoch.)

- Joël

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Aug 2020 11:26:18 -0400

Thanks for pointing this out, Joël.  I agree that the attacks you're
describing should work as things are currently specified.  And they're
salient, especially the "replace Alice in the group" one.

Also agree with Raphael is correct that Commit is not affected by this,
since someone who is not a member won't be able to generate the right
confirmation value.  However, I don't think this is actually the right
design to adopt for a general solution to this problem.  Confirmation
verifies group membership *after* processing the handshake message; the
point here is that we should also have a membership check *before*
processing handshake messages.  In particular, I would propose that we do
need something additional on Commit messages as well as Proposals.

Thinking about solutions here, a couple of options come to mind:

1. Use MLSCiphertext, but with an integrity-only encapsulation
2. Incorporate in the signature something that is only known to the group
(e.g., confirmation_key or MAC(confirmation_key; confirmed_transcript_hash
|| Proposal/Commit))

Option (1) has the appeal that you would only ever send MLSCiphertext,
though switching between encrypted/not could be problematic.  Option (2)
seems a lot more appealing: It doesn't add any overhead, since the
group-secret value doesn't need to be sent.  And we already switch between
the signature context that is added for group members vs. external.  In
fact, I think option (2) would just amount to a one-line change to include
an extra, secret value in the context at the top of the MLSPlaintextTBS
struct.
https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption

The only thing that seems odd about (2) is overloading signature
verification in that way, i.e., using the ability to generate a signature
over a secret thing to prove you know the secret thing.  That doesn't seem
obviously flawed to me, but worth thinking about.

Does that make sense to folks?

--Richard

On Tue, Aug 18, 2020 at 10:55 AM Raphael Robert <raphael=
[email-masked]> wrote:

> MLSPlaintext for HS messages. The recommendation is still to encrypt them
> and send them around as MLSCiphertext.
> Question: would this attack work with Commit messages? I’m thinking that
> they would be rejected because the attacker cannot compute the
> confirmation_tag.
>

---

From: Joel Alwen <[email-masked]>
Date: Tue, 18 Aug 2020 18:16:04 +0200

Yeah, I like Option 2 here. I like that it avoids growing packet size.

One caveat though: I'd go for the MAC(...) version rather than the
confirmation_key. For starters thing including confirmation_key doesnt
authenticate the contents of the packet. But even if it did, signatures aren't
meant to hide the contents of what was signed. (Amend you favorite sig scheme to
tack on the message at the end a signature and you've still got a secure
signature scheme. But clearly not a message hiding one.) That means that AFAIK
neither ECDSA nor EdDSA etc. were designed or analyzed for such a property. So
this would amount to a very non-standard use of a signature schemes by MLS. Not
saying it doesn't work for the particular sig schemes in our ciphersuite. But
its def. not how signatures are "meant" to be used.

But that leaves Option 2 with, say, including tag = MAC(conf_key,
conf_trans_hash || MLSPlaintext.content) into whats being signed which I like
and think gets the job done. Both conf_* values are taken from the current
epoch. By MLSPlaintext.content I mean whats now called MLSPlaintextTBS.

> I would propose that we do need something additional on Commit messages as
> well as Proposals.

@Richard: For Proopsals I think this works. Is that about what you had in mind
for commits too?

- Joël

On 18/08/2020 17:26, Richard Barnes wrote:
> Thanks for pointing this out, Joël.  I agree that the attacks you're describing
> should work as things are currently specified.  And they're salient, especially
> the "replace Alice in the group" one.
> 
> Also agree with Raphael is correct that Commit is not affected by this, since
> someone who is not a member won't be able to generate the right confirmation
> value.  However, I don't think this is actually the right design to adopt for a
> general solution to this problem.  Confirmation verifies group membership
> *after* processing the handshake message; the point here is that we should also
> have a membership check *before* processing handshake messages.  In particular,
> I would propose that we do need something additional on Commit messages as well
> as Proposals.
> 
> 2. Incorporate in the signature something that is only known to the group (e.g.,
> confirmation_key or MAC(confirmation_key; confirmed_transcript_hash ||
> Proposal/Commit))
> 
> Option (1) has the appeal that you would only ever send MLSCiphertext, though
> switching between encrypted/not could be problematic.  Option (2) seems a lot
> more appealing: It doesn't add any overhead, since the group-secret value
> doesn't need to be sent.  And we already switch between the signature context
> that is added for group members vs. external.  In fact, I think option (2) would
> just amount to a one-line change to include an extra, secret value in the
> context at the top of the MLSPlaintextTBS struct.
> The only thing that seems odd about (2) is overloading signature verification in
> that way, i.e., using the ability to generate a signature over a secret thing to
> prove you know the secret thing.  That doesn't seem obviously flawed to me, but
> worth thinking about.
> 
> On Tue, Aug 18, 2020 at 10:55 AM Raphael Robert
> <raphael=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Joel,
> 
>     they would be rejected because the attacker cannot compute the confirmation_tag.
> 
>     > On 18 Aug 2020, at 16:36, Joel Alwen <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hey everyone,
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Raphael Robert <[email-masked]>
Date: Tue, 18 Aug 2020 18:24:38 +0200

I think what you just described is indeed a combination of option 1 & 2. It’s a MAC over the payload we want to authenticate, but it’s implicit and we only include it in the MLSPlaintextTBS. Or in other words, we stripped it from MLSPlaintext because it is implicitly known to any valid member of the group.

Raphael

> On 18 Aug 2020, at 18:16, Joel Alwen <[email-masked]> wrote:
> 
>> <raphael=[email-masked] <mailto:raphael=[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>    Hi Joel,
>> 
>>> On 18 Aug 2020, at 16:36, Joel Alwen <[email-masked] <mailto:[email-masked]>
>>    <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> Hey everyone,
>>> 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
>> 
>>    [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>    https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>

---

From: Brendan McMillion <[email-masked]>
Date: Tue, 18 Aug 2020 09:34:41 -0700

> So to that end, how

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/

---

From: Joel Alwen <[email-masked]>
Date: Tue, 18 Aug 2020 18:55:07 +0200

> 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:
> 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 <[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Aug 2020 13:20:20 -0400

Sounds like we're converging here.  The only question in my mind is what
goes in the MAC -- seems like the easy option is probably "the remainder of
the MLSPlaintextTBS", i.e., everything from group_id to the end.  That
seems like it minimizes multiple serialization:

tbs_content = serialize(group_id, ...)
membership_token = KDF.Extract(confirmation_key, tbs_content)
tbs = group_context || membership_token || tbs_content

So the PR would be to basically pop the context off of MLSPlaintextTBS and
add the three lines above (with the switch for internal/external in prose).

Joël, do you want to write a PR?  If not, I could probably get to it in the
next couple days.

--Richard

On Tue, Aug 18, 2020 at 12:24 PM Raphael Robert <[email-masked]> wrote:

> I think what you just described is indeed a combination of option 1 & 2.
> It’s a MAC over the payload we want to authenticate, but it’s implicit and
> we only include it in the MLSPlaintextTBS. Or in other words, we stripped
> it from MLSPlaintext because it is implicitly known to any valid member of
> the group.
>
> Raphael
>
> describing
> since
> well
> (e.g.,
> though
> verification in
> <raphael=[email-masked] <mailto:[email-masked]
> <[email-masked]>>> wrote:
>
>    Hi Joel,
>
>    <mailto:[email-masked] <[email-masked]>>> wrote:
>
>
> Hey everyone,
>
> Suppose Alice is in a group using signing key pair (spk, ssk). I corrupt
>
>    her to
>
> key package with her same spk but a new HPKE key for her leaf. She sends
>
>    out and
>
> 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
>
> longer know the group's key schedule and so can't forged packet from
>
>    Alice. More
>
> PS. For concreteness, we could probably extend the current mechanism for
>
>    getting
>
> concistancy (the confirmation_tag) to also provide symmetric key
>
>    authentication.
>
> confirmation_tag. That would cover the case of a commit packet and doesn't
>
>    even
>
> computed using the *current* epoch's confirmation_key and
>
>    confirmed_transcript_hash.
>
>
> [email-masked] <mailto:[email-masked] <[email-masked]>>
>    [email-masked] <mailto:[email-masked] <[email-masked]>>

---

From: Joel Alwen <[email-masked]>
Date: Tue, 18 Aug 2020 19:30:22 +0200

> Joël, do you want to write a PR?  If not, I could probably get to it in the

Thanks. :-) If you could that would be really nice.

- Joël

On 18/08/2020 19:20, Richard Barnes wrote:
> Sounds like we're converging here.  The only question in my mind is what goes in
> the MAC -- seems like the easy option is probably "the remainder of the
> MLSPlaintextTBS", i.e., everything from group_id to the end.  That seems like it
> minimizes multiple serialization:
> 
> So the PR would be to basically pop the context off of MLSPlaintextTBS and add
> the three lines above (with the switch for internal/external in prose).
> 
> Joël, do you want to write a PR?  If not, I could probably get to it in the next
> couple days.
> 
> --Richard
> 
> On Tue, Aug 18, 2020 at 12:24 PM Raphael Robert <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     we only include it in the MLSPlaintextTBS. Or in other words, we stripped it
>     from MLSPlaintext because it is implicitly known to any valid member of the
>     group.
> 
>     Raphael
> 
>>     On 18 Aug 2020, at 18:16, Joel Alwen <[email-masked]
>>>     <raphael=[email-masked]
>>>     <mailto:raphael=[email-masked]> <mailto:[email-masked]>>
>>>     wrote:
>>>
>>>        Hi Joel,
>>>
>>>>     <mailto:[email-masked]>
>>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>        [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Brendan McMillion <[email-masked]>
Date: Tue, 18 Aug 2020 10:36:53 -0700

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 <[email-masked]> 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.
>
> signatures
> > vector:

---

From: Joel Alwen <[email-masked]>
Date: Tue, 18 Aug 2020 20:25:53 +0200

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, <[email-masked]>
wrote:

>> in the

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Aug 2020 15:01:20 -0400

Here ya go: https://github.com/mlswg/mls-protocol/pull/396

On Tue, Aug 18, 2020 at 1:30 PM Joel Alwen <[email-masked]> wrote:

> goes in
> >>     meant to hide the contents of what was signed. (Amend you favorite
> sig
> >>     scheme to
> >>     this would amount to a very non-standard use of a signature schemes
> by
> >>     MLS. Not
> >>>     should work as things are currently specified.  And they're
> salient,
> >>>     especially
> >>>     value.  However, I don't think this is actually the right design
> to adopt
> >>>     for a
> >>>     I would propose that we do need something additional on Commit
> messages
> >>>     as well
> >>>     as Proposals.
> >>>
> >>>     that is added for group members vs. external.  In fact, I think
> option
> >>>     (2) would
> >>>     that way, i.e., using the ability to generate a signature over a
> secret
> >>>     thing to
> >>>     prove you know the secret thing.  That doesn't seem obviously
> flawed to
> >>>     me, but
> >>>     worth thinking about.
> >>>
> >>>        That being said, we said we would like to support scenarios
> where HS
> >>>        messages are not necessarily encrypted.
> >>>
> >>>        I’d be interested to see what exactly you would propose as a
> mitigation
> >>>        mechanism.
> >>>
> >>>        Raphael
> >>>
> >>>>     Something thats been bugging Marta Mularczyk and Daniel Jost and
> me for
> >>>>     a bit
> >>>>     non-members that makes sense but for group members that's weaker
> than
> >>>>     need be.
> >>>>
> >>>>     learn ssk. Now I loose access to her device again. Later she
> generates a
> >>>>     fresh
> >>>>     must also be authenticated using something from the application
> key
> >>>>     schedule.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Aug 2020 15:19:54 -0400

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 <[email-masked]> wrote:

> 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.
>
>>> > My objection to this is that Alice can still be impersonated by
>>> members in the group, if we only have symmetric forward-secure
>>> authentication.
>>>
>>> key schedule.
>>> me for a bit
>>> than need be.
>>> generates a fresh
>>> key schedule.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Aug 2020 15:21:20 -0400

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.

---

From: Brendan McMillion <[email-masked]>
Date: Tue, 18 Aug 2020 15:08:24 -0700

> members of the group could only impersonate Alice if they had compromised

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 <[email-masked]> wrote:

> [email-masked] <[email-masked]>> wrote:
>
>> So to that end, how

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Wed, 19 Aug 2020 00:43:07 +0000

It is true that this only addresses one aspect and that rotating signature keys is the correct answer, especially with respect to PCS. The currently proposed solution only provides a mitigation to the *current* group. PCS in concurrent groups and those groups that the member has not yet joined is not covered by the proposed solution, while it would be through rotation of signing keys.

That said, if rotation of signature keys is not going to be considered at all for the spec, then mitigating just one of these attacks is better than nothing.

Britta

From: MLS <[email-masked]> on behalf of Brendan McMillion <brendan=[email-masked]>
Date: Tuesday, August 18, 2020 at 3:08 PM
To: Richard Barnes <[email-masked]>
Cc: Messaging Layer Security WG <[email-masked]>, Joel Alwen <[email-masked]>
Subject: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule

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 <[email-masked]> 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=[email-masked]<mailto:[email-masked]>> 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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hey everyone,

Any thoughts?

- Joël

_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mls

---

From: Raphael Robert <[email-masked]>
Date: Wed, 19 Aug 2020 09:24:22 +0200

I thought about this some more and now I’m not sure that the membership_token should only be implicit:

The whole reason for HS messages to not be encrypted is that they can be inspected along the way by an external party (e.g. the Delivery Service). If this is not a requirement, MLSCiphertext should really be used instead.
Hiding the membership_token from external inspector means the inspector can not verify the signature anymore. I think that defies the point of HS messages being inspectable.

The obvious fix is to include the membership_token in MLSPlaintext as well.

Raphael

> On 18 Aug 2020, at 21:01, Richard Barnes <[email-masked]> wrote:
> 
> Here ya go: https://github.com/mlswg/mls-protocol/pull/396 <https://github.com/mlswg/mls-protocol/pull/396>
> On Tue, Aug 18, 2020 at 1:30 PM Joel Alwen <[email-masked] <mailto:[email-masked]>> wrote:
> > On Tue, Aug 18, 2020 at 12:24 PM Raphael Robert <[email-masked] <mailto:[email-masked]>
> > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> > 
> >>     On 18 Aug 2020, at 18:16, Joel Alwen <[email-masked] <mailto:[email-masked]>
> >>>     https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption>
> >>>
> >>>     <raphael=[email-masked] <mailto:[email-masked]>
> >>>     <mailto:raphael <mailto:raphael>=[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>>>
> >>>     wrote:
> >>>
> >>>        Hi Joel,
> >>>
> >>>>     <mailto:[email-masked] <mailto:[email-masked]>>
> >>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>>
> >>>        [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Cornelissen Eric <[email-masked]>
Date: Wed, 19 Aug 2020 08:17:44 +0000

I was wondering what the implications are of using the key advertised in an update Proposal's KeyPackage for signing, instead of the long-term key pair, just like new_member external proposals<https://github.com/mlswg/mls-protocol/blob/c3db39266505e9d202158d642d65918d35870e77/draft-ietf-mls-protocol.md#external-proposals>. I'm confident it prevents the original weakness pointed out by Joël, but I'm unsure as to whether or not it introduces any new problems.

Then again, I would be very much in favor of including something group-binding in handshake messages as it would prevent some replay attacks (*) that I have been considering for a while.

Regards,

Eric

(*): Replays from adversarially controlled groups where the attacker managed to have the group id, epoch, and tree structure to match those of a target group.

________________________________
From: Richard Barnes <[email-masked]>
Sent: Tuesday, August 18, 2020 6:26 PM
To: Raphael Robert
Cc: Joel Alwen; Messaging Layer Security WG
Subject: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule

Thanks for pointing this out, Joël.  I agree that the attacks you're describing should work as things are currently specified.  And they're salient, especially the "replace Alice in the group" one.

Also agree with Raphael is correct that Commit is not affected by this, since someone who is not a member won't be able to generate the right confirmation value.  However, I don't think this is actually the right design to adopt for a general solution to this problem.  Confirmation verifies group membership *after* processing the handshake message; the point here is that we should also have a membership check *before* processing handshake messages.  In particular, I would propose that we do need something additional on Commit messages as well as Proposals.

1. Use MLSCiphertext, but with an integrity-only encapsulation
2. Incorporate in the signature something that is only known to the group (e.g., confirmation_key or MAC(confirmation_key; confirmed_transcript_hash || Proposal/Commit))

Option (1) has the appeal that you would only ever send MLSCiphertext, though switching between encrypted/not could be problematic.  Option (2) seems a lot more appealing: It doesn't add any overhead, since the group-secret value doesn't need to be sent.  And we already switch between the signature context that is added for group members vs. external.  In fact, I think option (2) would just amount to a one-line change to include an extra, secret value in the context at the top of the MLSPlaintextTBS struct.
https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption
[https://avatars1.githubusercontent.com/u/36107802?s=400&v=4]<https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption>

mls-protocol/draft-ietf-mls-protocol.md at master · mlswg/mls-protocol · GitHub<https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption>
github.com
MLS protocol. Contribute to mlswg/mls-protocol development by creating an account on GitHub.

The only thing that seems odd about (2) is overloading signature verification in that way, i.e., using the ability to generate a signature over a secret thing to prove you know the secret thing.  That doesn't seem obviously flawed to me, but worth thinking about.

--Richard

On Tue, Aug 18, 2020 at 10:55 AM Raphael Robert <raphael=[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel,

Raphael

> On 18 Aug 2020, at 16:36, Joel Alwen <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hey everyone,
>

---

From: Joel Alwen <[email-masked]>
Date: Thu, 20 Aug 2020 16:20:49 +0200

Yeah, good point. While I'm not sure every case of server inspection would
require checking sigs on packets I am sure it would be useful for some cases.

> The obvious fix is to include the membership_token in MLSPlaintext as well.

Yup, I'm all for it. (Or at least for making it an optional field in that struct.)

- Joël

On 19/08/2020 09:24, Raphael Robert wrote:
> The whole reason for HS messages to not be encrypted is that they can be
> inspected along the way by an external party (e.g. the Delivery Service). If
> this is not a requirement, MLSCiphertext should really be used instead.
> Hiding the membership_token from external inspector means the inspector can not
> verify the signature anymore. I think that defies the point of HS messages being
> inspectable.
> 
>> On 18 Aug 2020, at 21:01, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     <mailto:[email-masked]>
>>     messages as
>>     >>>     <mailto:raphael <mailto:raphael>=[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked]
>>     <mailto:[email-masked]>>>
>>     >>>     wrote:
>>     >>>
>>     >>>        Hi Joel,
>>     >>>
>>     >>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>>
>>     >>>        [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Joel Alwen <[email-masked]>
Date: Thu, 20 Aug 2020 17:01:55 +0200

Hey Eric,

What I think ur saying here is that an update proposal (MLSPLaintext) packets
should be signed using the sig key contained in that packet's key package. Am I
getting that right?

This makes no difference for the forging of Add and Remove proposals so those
attacks should still work as before. It might prevent forging updates but only
if both:

A) all updates proposals MUST update to new credentials and
B) when leaking Alice's state I only obtained 1 valid credential of hers.

But for that we'd have to mandate A) as thats not currently the case. I think
would be a mistake though, at least in general. Fresh certs may be comparatively
difficult to come by even for honest users. Yet that shouldn't stop them from
updating their HPKE keys frequently. At best, maybe this could be a group
specific policy? E.g. for deployments where fresh certs are very easy to come by
(say, generated locally) so people could be expected to refresh their sig keys
just as often as their HPKE keys.

> Then again, I would be very much in favor of including something group-binding
> in handshake messages as it would prevent some replay attacks (*) that I have
> been considering for a while.

Yup, this seems more like a complimentary solution.

I'm curious about those replay attacks though! :-) If you're ready to tell us
more I'm all ears...

- Joël

On 19/08/2020 10:17, Cornelissen Eric wrote:
> I was wondering what the implications are of using the key advertised in an
> update Proposal's KeyPackage for signing, instead of the long-term key pair,
> just like new_memberexternal proposals
> <https://github.com/mlswg/mls-protocol/blob/c3db39266505e9d202158d642d65918d35870e77/draft-ietf-mls-protocol.md#external-proposals>.
> I'm confident it prevents the original weakness pointed out by Joël, but I'm
> unsure as to whether or not it introduces any new problems.
> 
> 
> Then again, I would be very much in favor of including something group-binding
> in handshake messages as it would prevent some replay attacks (*) that I have
> been considering for a while.
> 
> 
> Regards,
> 
> Eric
> 
> 
> 
> (*): Replays from adversarially controlled groups where the attacker managed to
> have the group id, epoch, and tree structure to match those of a target group.
> 
> 
> 
> --------------------------------------------------------------------------------
> *From:* Richard Barnes <[email-masked]>
> *Sent:* Tuesday, August 18, 2020 6:26 PM
> *To:* Raphael Robert
> *Cc:* Joel Alwen; Messaging Layer Security WG
> *Subject:* Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric
> key schedule
>  
> <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption>
> 	
> mls-protocol/draft-ietf-mls-protocol.md at master · mlswg/mls-protocol · GitHub
> <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption>
> github.com

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Aug 2020 14:55:11 -0400

> Yup, I'm all for it. (Or at least for making it an optional field in that

The PR has been updated.  There is now a member_token field before the
signature, which non-member senders set to zero length.

https://github.com/mlswg/mls-protocol/pull/396/files

Note that this allows the server to verify the signature, but the
membership_token is opaque to it; the server can't authenticate the
sender's membership.

--Richard

> > I thought about this some more and now I’m not sure that the
> membership_token
> > should only be implicit:
> >
> >>     > MLSPlaintextTBS", i.e., everything from group_id to the end.
> That seems
> >>     like it
> >>     > So the PR would be to basically pop the context off of
> MLSPlaintextTBS
> >>     and add
> >>     > Joël, do you want to write a PR?  If not, I could probably get to
> it in
> >>     the next
> >>     > couple days.
> >>     >
> >>     > --Richard
> >>     >
> >>     >     we only include it in the MLSPlaintextTBS. Or in other words,
> we
> >>     stripped it
> >>     >     from MLSPlaintext because it is implicitly known to any valid
> member
> >>     of the
> >>     >     group.
> >>     >
> >>     >     Raphael
> >>     >
> >>     >>     meant to hide the contents of what was signed. (Amend you
> favorite sig
> >>     >>     scheme to
> >>     >>     tack on the message at the end a signature and you've still
> got a
> >>     secure
> >>     >>     signature scheme. But clearly not a message hiding one.)
> That means
> >>     that AFAIK
> >>     >>     neither ECDSA nor EdDSA etc. were designed or analyzed for
> such a
> >>     property. So
> >>     >>     this would amount to a very non-standard use of a signature
> schemes by
> >>     >>     MLS. Not
> >>     >>     conf_trans_hash || MLSPlaintext.content) into whats being
> signed
> >>     which I like
> >>     >>     and think gets the job done. Both conf_* values are taken
> from the
> >>     current
> >>     >>     @Richard: For Proopsals I think this works. Is that about
> what you
> >>     had in mind
> >>     >>     for commits too?
> >>     >>
> >>     >>     - Joël
> >>     >>
> >>     >>
> >>     >>>     Also agree with Raphael is correct that Commit is not
> affected by
> >>     this, since
> >>     >>>     someone who is not a member won't be able to generate the
> right
> >>     confirmation
> >>     >>>     general solution to this problem.  Confirmation verifies
> group
> >>     membership
> >>     >>>     *after* processing the handshake message; the point here is
> that we
> >>     >>>     should also
> >>     >>>     have a membership check *before* processing handshake
> messages.  In
> >>     >>>     particular,
> >>     >>>     2. Incorporate in the signature something that is only
> known to
> >>     the group
> >>     >>>     (e.g.,
> >>     >>>     switching between encrypted/not could be problematic.
> Option (2)
> >>     seems a lot
> >>     >>>     that is added for group members vs. external.  In fact, I
> think option
> >>     >>>     (2) would
> >>     >>>     just amount to a one-line change to include an extra,
> secret value
> >>     in the
> >>     >>>        MLSPlaintext for HS messages. The recommendation is
> still to
> >>     encrypt them
> >>     >>>        Question: would this attack work with Commit messages?
> I’m
> >>     thinking that
> >>     >>>        As you mention in the PS, the easy target would be
> Proposal
> >>     messages.
> >>     >>>
> >>     >>>>     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
> >>     >>>>     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.
> >>     >>>>
> >>     >>>>     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
> >>     >>>>     - 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.
> >>     >>>>
> >>     >>>>     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
> >>     >>>>     generally, this brings the PCS guarantees when using
> MLSPlaintexts
> >>     >>>>     frameing in
> >>     >>>>     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
> >>     >>>>     For a proposal packet we could also have a
> confirmation_tag but
> >>     this one is

---

From: Cornelissen Eric <[email-masked]>
Date: Fri, 21 Aug 2020 06:28:20 +0000

Hi Joël,

Thanks for getting back to me. I was indeed assuming A (i.e. that the updated credentials are fresh), but didn't think about the practicalities of getting new credentials. *After* such an update it should also prevent the adversary from forging Add and Remove proposals.

Regards,

Eric

________________________________
From: Joel Alwen <[email-masked]>
Sent: Thursday, August 20, 2020 6:01:55 PM
To: Cornelissen Eric; Richard Barnes; Raphael Robert
Cc: Messaging Layer Security WG
Subject: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule

Hey Eric,

- Joël

> <https://github.com/mlswg/mls-protocol/blob/c3db39266505e9d202158d642d65918d35870e77/draft-ietf-mls-protocol.md#external-proposals>.
[https://avatars1.githubusercontent.com/u/36107802?s=400&v=4]<https://github.com/mlswg/mls-protocol/blob/c3db39266505e9d202158d642d65918d35870e77/draft-ietf-mls-protocol.md#external-proposals>

mls-protocol/draft-ietf-mls-protocol.md at c3db39266505e9d202158d642d65918d35870e77 · mlswg/mls-protocol · GitHub<https://github.com/mlswg/mls-protocol/blob/c3db39266505e9d202158d642d65918d35870e77/draft-ietf-mls-protocol.md#external-proposals>
github.com
MLS protocol. Contribute to mlswg/mls-protocol development by creating an account on GitHub.

---

From: Raphael Robert <[email-masked]>
Date: Fri, 21 Aug 2020 11:49:33 +0200

Thanks Richard, I think this now meets all requirements as such. However, I stumbled upon the (group) context field that is already in MLSPlaintextTBS. Wouldn’t this

	a) mean that the server cannot verify a signature of a member, since the group context is not known outside of the group?
	b) address Joel’s concerns in the first place?

I’m a bit confused as to what the intention was initially when we introduced that. Right now it doesn’t seem to serve any extra purpose and I think we could remove it.

Raphael

> On 20 Aug 2020, at 20:55, Richard Barnes <[email-masked]> wrote:
> 
> On Thu, Aug 20, 2020 at 10:20 AM Joel Alwen <[email-masked] <mailto:[email-masked]>> wrote:
> The PR has been updated.  There is now a member_token field before the signature, which non-member senders set to zero length.
> 
> https://github.com/mlswg/mls-protocol/pull/396/files <https://github.com/mlswg/mls-protocol/pull/396/files>
> 
> Note that this allows the server to verify the signature, but the membership_token is opaque to it; the server can't authenticate the sender's membership.
> 
> --Richard 
>  
> 
> - Joël
> 
> >> On 18 Aug 2020, at 21:01, Richard Barnes <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>
> >> On Tue, Aug 18, 2020 at 1:30 PM Joel Alwen <[email-masked] <mailto:[email-masked]>
> >>     <mailto:[email-masked] <mailto:[email-masked]>>
> >>     > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> >>     >
> >>     >>     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> >>     >>
> >>     >>>     <raphael=[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >>     >>>     <mailto:raphael <mailto:raphael> <mailto:raphael <mailto:raphael>>=[email-masked] <mailto:[email-masked]>
> >>     <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]>
> >>     <mailto:[email-masked] <mailto:[email-masked]>>>>
> >>     >>>     wrote:
> >>     >>>
> >>     >>>        Hi Joel,
> >>     >>>
> >>     >>>>     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >>     >>>        <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> >>     >>>>
> >>     >>>>     Hey everyone,
> >>     >>>>
> >>     >>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> >>     <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
> >>     >>>        [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
> >>     <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Aug 2020 15:03:58 -0400

To close the loop on context: As mentioned on the call, the content of the
GroupContext is public, so it shouldn't interfere with the DS verifying
signatures.

After the discussion on the interim call today, I made two updates to this
PR:
1. Use an explicit MAC and separate keys
https://github.com/mlswg/mls-protocol/pull/396/commits/10e1ba799e44a7e858d7832ec5c6c39bd214010a
2. Have the membership MAC cover the signature
https://github.com/mlswg/mls-protocol/pull/396/commits/52a06e4021d654c60afea85681f4cb2c91bd05f1

We didn't really close on the latter change on the call, but it seems like
it adds a bit more rigidity than the parallel MAC-and-Sign construction we
had before, and makes things more parallel to MLSCiphertext.  (Puts me in
mind of the encrypt-then-MAC / MAC-then-encrypt / encrypt-and-MAC
discussions of yore.)

On Fri, Aug 21, 2020 at 5:49 AM Raphael Robert <[email-masked]> wrote:

> Thanks Richard, I think this now meets all requirements as such. However,
> I stumbled upon the (group) context field that is already in
> MLSPlaintextTBS. Wouldn’t this
>
> a) mean that the server cannot verify a signature of a member, since the
> group context is not known outside of the group?
> I’m a bit confused as to what the intention was initially when we
> introduced that. Right now it doesn’t seem to serve any extra purpose and I
> think we could remove it.
>
> Raphael
>
>> >>     > Joël, do you want to write a PR?  If not, I could probably get
>> to it in
>> >>     the next
>> >>     > couple days.
>> >>     >
>> >>     > --Richard
>> >>     >
>> >>     >     we only include it in the MLSPlaintextTBS. Or in other
>> words, we
>> >>     stripped it
>> >>     >     from MLSPlaintext because it is implicitly known to any
>> valid member
>> >>     of the
>> >>     >     group.
>> >>     >
>> >>     >     Raphael
>> >>     >
>> >>     >>>     should work as things are currently specified.  And
>> they're salient,
>> >>     >>>     especially
>> >>     >>>     *after* processing the handshake message; the point here
>> is that we
>> >>     >>>     should also
>> >>     >>>>     Actual result: using her stolen ssk I can still forge a
>> new
>> >>     proposal's
>> >>     >>>        (sent as
>> >>     >>>>     - I could forge Add's and Remove's coming from Alice, so
>> I could
>> >>     trick the