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

[Alexander Sherkin <[e-mail]>]

Hi Emad,

Thank you for your comments. Please find a couple of comments below inline.

Thanks.
Alex.




Alexander Sherkin
        Software Architect



[cid:imageb2e661.PNG@37550bb1.42913d22]<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: MLS [mailto:[e-mail]] On Behalf Of Emad Omara
Sent: April 18, 2019 11:41 PM
To: Alexander Sherkin <[e-mail]>
Cc: [e-mail]
Subject: Re: [MLS] Blocking Update messages for breaking post-compromise security



On Thu, Apr 18, 2019 at 11:55 AM Alexander Sherkin <[e-mail]<mailto:[e-mail]>> wrote:
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.
This is actually the current assumption in the architecture document, each device is represented as a separate client, however we are also currently looking into using a virtual client mode where all devices are presented in a single node.

[Alex] Does it mean that I do not need to control all A’s devices, and preventing just one device from sending Updates will make attack successful?

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?
Well, I see this as just a recommendation to the app, not sure what can be done at the protocol layer!

[Alex] Say I want to integrate MLS into my app and follow the recommendation of kicking devices that have not sent Update recently. This means that devices that have been offline for a while (vacation, etc) will be unable to participate in the group after they are back online. Ideally, as an app developer, I would want these devices to be able to re-join gracefully so we are back in “Self-Add” problem domain.

I guess the app may allow devices to re-join by sending all users Add command essentially resetting the ratchet tree, but is it the best approach? Should there be more guidance from the protocol? Or should the protocol explicitly state when devices should remove inactive leaf nodes? If this decision is not part of the protocol, it may not be clear what post-compromise security properties are guaranteed by the protocol.


Thank you.
Alex.




Alexander Sherkin

Software Architect



[cid:image001.png@01D4F924.1963D960]<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>
EMAlexander.Sherkin@darkmatter..ae<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]<mailto:[e-mail]>]
Sent: April 17, 2019 5:12 PM
To: Alexander Sherkin <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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