Subject: [MLS] Blocking Update messages for breaking post-compromise security

From: Alexander Sherkin <[email-masked]>
Date: Wed, 17 Apr 2019 20:57:46 +0000

Hello,

I think we briefly discussed this problem in the context of “inactive users”, but I want to bring this up again for discussion.

Let’s assume an attacker compromises user A and recovers user A’s cryptographic state including the leaf secret. After user A is compromised, the attacker no longer controls user A. User A will eventually send an Update message, and the attacker will no longer have access to the root key. We get post-compromise security property.

However, let’s assume that after compromising user A and recovering user A crypto state, the attacker performs a denial of service attack on user A Update messages (or all messages from user A). The attacker then observes the traffic. The attacker will be able to decrypt Update messages from other participants and decrypt data-carrying messages as long as other participants include user A in their ratchet trees.

As an interesting thought experiment, we can try to apply the same attack to one-on-one use case when double ratcheting is used. To prevent ratcheting, the attacker has to block messages from one of the participants. Practically, this means that the attacker destroys the possibility of two participants having a conversation; hence, data collected by the attack will be one participants’ monologue and may not be as valuable. In contrast, when 1 out of 1000 users is isolated, 999 remaining users will continue having productive conversation creating valuable data that the attacker may intercept and decrypt.

If the above attack vector makes sense, should we consider excluding users who did not send Update messages recently enough from the ratchet tree?

Thank you.
Alex.

Alexander Sherkin
        Software Architect

<http://www.darkmatter.ae>

2 Robert Speck Parkway, Suite 1610
Mississauga ON  L4Z 1H8
Canada
MT+1 416 414 7117<tel:+1%20416%20414%207117>
[email-masked]<mailto:[email-masked]>

darkmatter.ae<http://darkmatter.ae>

[Linkedin]<https://www.linkedin.com/company/dark-matter-llc> [Twitter] <https://twitter.com/GuardedbyGenius>

The information in this email is intended only for the person(s) or entity to whom it is addressed and may contain confidential or privileged information. If you receive this email by error, please notify us immediately, delete the original message and do not disclose the contents to any other person, use or store or copy the information in any medium and for whatever purpose. Any unauthorized use is strictly prohibited.

---

From: Emad Omara <[email-masked]>
Date: Wed, 17 Apr 2019 14:11:46 -0700

Hi Alex,

I think the attack makes sense, however it assumes the attacker has some
sort of control for the network of all A's devices in order to perform the
DoS. One mitigation we discussed before that could help in this attack is
to force the max update window, so if a client has issued any update in the
last N days, the app can decide to kick it out of the group, ot at least
issue a warning to other users.

Emad

On Wed, Apr 17, 2019 at 1:58 PM Alexander Sherkin <
[email-masked]> wrote:

> Hello,
>
>
>
> I think we briefly discussed this problem in the context of “inactive
> users”, but I want to bring this up again for discussion.
>
>
>
> Let’s assume an attacker compromises user A and recovers user A’s
> cryptographic state including the leaf secret. After user A is compromised,
> the attacker no longer controls user A. User A will eventually send an
> Update message, and the attacker will no longer have access to the root
> key. We get post-compromise security property.
>
>
>
> However, let’s assume that after compromising user A and recovering user A
> crypto state, the attacker performs a denial of service attack on user A
> Update messages (or all messages from user A). The attacker then observes
> the traffic. The attacker will be able to decrypt Update messages from
> other participants and decrypt data-carrying messages as long as other
> participants include user A in their ratchet trees.
>
>
>
> As an interesting thought experiment, we can try to apply the same attack
> to one-on-one use case when double ratcheting is used. To prevent
> ratcheting, the attacker has to block messages from one of the
> participants. Practically, this means that the attacker destroys the
> possibility of two participants having a conversation; hence, data
> collected by the attack will be one participants’ monologue and may not be
> as valuable. In contrast, when 1 out of 1000 users is isolated, 999
> remaining users will continue having productive conversation creating
> valuable data that the attacker may intercept and decrypt.
>
>
>
> If the above attack vector makes sense, should we consider excluding users
> who did not send Update messages recently enough from the ratchet tree?
>
>
>
> Thank you.
>
> Alex.
>
>
>
>
>
>
>
>
>
>
>
>
> Alexander Sherkin
> Software Architect
>
> *MT*+1 416 414 7117 <+1%20416%20414%207117>
> [email-masked]
>
> darkmatter.ae
>
>  <https://www.linkedin.com/company/dark-matter-llc> [image:
> Twitter] <https://twitter.com/GuardedbyGenius>
>
>
> The information in this email is intended only for the person(s) or entity
> to whom it is addressed and may contain confidential or privileged
> information. If you receive this email by error, please notify us
> immediately, delete the original message and do not disclose the contents
> to any other person, use or store or copy the information in any medium and
> for whatever purpose. Any unauthorized use is strictly prohibited.
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>