Re: [MLS] Re-randomized TreeKEM

[Brendan McMillion <[e-mail]>]

>
> Let us assume the adversary compromised the initial state of some member
> of a group at t=0. In either version of TreeKEM: once that group member
> has successfully updated their state, the adversary will no longer have
> access to the current group secret. However, if we ever throw out that
> member and have them rejoin, the adversary has a way back into the
> group. The group does not know whether the initial member rejoined, or
> the adversary posing as the initial member. Likewise, the initial member
> loses their guarantee on the rest of the group's identity/security.
>

 Ah, when an adversary compromises a user, the user's ClientInitKeys are
also compromised. That's a really interesting point.

This attack doesn't work in RTreeKEM because the user updated their
> state after receiving the message at timepoint t. This attack doesn't
> work in TreeKEM with ACKs because the user will have updated their state
> and sent an update message at t+0.5.
>

This doesn't agree with my understanding of MLS. The way I'm reading your
example, AEAD(m, ...) is application data? There's a section in the spec
titled "Sender Ratchets" that describes how after application data is
decrypted, the symmetric decryption key and anything that you might be able
to derive it from is erased. So all of that erasing happens at t+1 and the
adversary has nothing to work with at t+2.

If on the other hand, AEAD(m, ...) is referring to something in the
handshake messages, that shouldn't be an issue either. Yes, the ciphertexts
can still be decrypted but epoch_secret[n] = HKDF(init_secret[n-1] ||
update_secret) where update_secret is what's decrypted, and
init_secret[n-1] was deleted after the handshake message was processed. The
adversary shouldn't have access to init_secret[n-1], so he can't compute
the next epoch secret.

---

I think I got your point, Brendan, and why we kept speaking past each
> other! And we are partially guilty here, by occasionally using the
> term "recover" to mean  two different things, contributing to the
> confusion.
>

I think I was using "recover" to refer to achieving both FS and PCS
simultaneously. Once the adversary is kicked out of the group, you have
PCS, but in TreeKEM you need to wait a bit to ensure future compromises
won't reveal past messages.

Whether this difference is "gargantuan" is a matter of taste.
>

I agree it's a matter of taste, which is why I don't expect to change my
mind. It's also why you won't hear me complain if the change is adopted
anyways. RTreeKEM has objectively better security.