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

[Alexander Sherkin <[e-mail]>]

Hi Emad,

Could there be a setup where each A’s point of presence (device) participates as a separate leaf in the ratchet tree? The advantage of such approach may be to avoid the key synchronization problem between points of presence.

Do you see the mechanism of removing users who did not send Updates recently should be part of the protocol or should it be driven by the app?

Thank you.
Alex.





Alexander Sherkin
        Software Architect



[cid:image53017f.PNG@6b191aba.42ae383e]<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>
[e-mail]<mailto:[e-mail]>

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 [mailto:[e-mail]]
Sent: April 17, 2019 5:12 PM
To: Alexander Sherkin <[e-mail]>
Cc: [e-mail]
Subject: Malware[SUSPICIOUS MESSAGE] It may trick victims into clicking a link and downloading malware. Do not open suspicious links.Re: [MLS] Blocking Update messages for breaking post-compromise security

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 <[e-mail]<mailto:[e-mail]>> 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



[cid:image001.png@01D4F5C7.2D8B06D0]<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>
[e-mail]<mailto:[e-mail]>

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.
_______________________________________________
MLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mls