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

Emad Omara <emadomara@google.com> Fri, 19 April 2019 03:40 UTC

Return-Path: <emadomara@google.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAC8120268 for <mls@ietfa.amsl.com>; Thu, 18 Apr 2019 20:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgKasZ2B2_0e for <mls@ietfa.amsl.com>; Thu, 18 Apr 2019 20:40:54 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C72B120266 for <mls@ietf.org>; Thu, 18 Apr 2019 20:40:53 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id w15so5065192wmc.3 for <mls@ietf.org>; Thu, 18 Apr 2019 20:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EthggRPQVO6GGINvOardvh7OTjmF+z40qz2w0WSDu9I=; b=C3L1lMMclmYK5EWIJNwT6+COS2xsrZ42kIRJmrpQBSGtWmdEtuB/8x4F07lEb0OUQF GdsDI8D2zjaJAQ2WF/Ye+vEnYpP3b4fdrHkovfMa6eyNsPSQgaLG6NignU/5K/l+nZ6c aGLl8MDojNDwfALTXjGkavChxN4WLnWJmqyh8qwp8/+XFSrU0iPbgw7tPgwxA6NmPgfh XXUv7r9WfXXjKWYNXspAPExHrInLSERVQklBB3r9HzGwCGIO0fpVQpuuB749JkIgNfyK QGonJBKcTcwXeHPZZcOghEdwzqKLE6GMYuIqvX9celXg1Jh98gNp/ug8L3JiFq9F8wWU yIxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EthggRPQVO6GGINvOardvh7OTjmF+z40qz2w0WSDu9I=; b=HZHA4eC4zp1c26mq95bbtLsnqcMZaFai7j2Yza9JKD02F4QWm+SfErm/7eiDi4DooV Ui9idzDsS3yJlqleOrykdHfrdk5ye25wLGdUGKKTGxeSw3KQNhaEzcHvNNJR9cMF9o7B xG6NMrArZzcuPljqgVwxy25rHKFNqKi1Bv4UFvj/KPVprz0VZZ/957c5B9IQwrBgp6Sx 7ciCBzYtcfQEu1DXdrPatQVf2IrxVRjLs1IlrhTfCxL4xPUREFflGxOp7EtlLLQvwf5f EAxESsFz4u/zI0ZuICzgP9qpd2nnSsYa8d/2Vy8euRN7B7irYA+Tf/lIgKOj+ZoegRLM +lsg==
X-Gm-Message-State: APjAAAUxwKVE+y2wQC5N7Hcsz28M1Q6f63S2Sz0R6hnVAqu6X6FJGOUx txZBGEsKiS/hiu2LxzpssXtoRtTbDqB55LWE+7Dn
X-Google-Smtp-Source: APXvYqxHDlDJkChNX7/z9iwD2FVWuhmQQq9VeQ9avhxZflO32LFOf7eL2lWD1ooBeyeiZwa+rIqp3HsPBaOJWWstIws=
X-Received: by 2002:a1c:eb18:: with SMTP id j24mr1095781wmh.32.1555645251193; Thu, 18 Apr 2019 20:40:51 -0700 (PDT)
MIME-Version: 1.0
References: <f57fdfc23287463cb3ad3713faaf25b4@darkmatter.ae>
In-Reply-To: <f57fdfc23287463cb3ad3713faaf25b4@darkmatter.ae>
From: Emad Omara <emadomara@google.com>
Date: Thu, 18 Apr 2019 20:40:40 -0700
Message-ID: <CAHo7dC8+T15Wd3C8DPYzeNNBNQ=kLVbqrNpVnaE73me6cs1tgw@mail.gmail.com>
To: Alexander Sherkin <Alexander.Sherkin@darkmatter.ae>
Cc: "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/related; boundary="00000000000099395a0586d9e266"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/8LrmJTjEpQMCSYd5cIodTy5t-WU>
Subject: Re: [MLS] Blocking Update messages for breaking post-compromise security
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 03:40:57 -0000

On Thu, Apr 18, 2019 at 11:55 AM Alexander Sherkin <
Alexander.Sherkin@darkmatter.ae> 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.

>
>
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!

>
>
> 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 <+1%20416%20414%207117>
> *EM*Alexander.Sherkin@darkmatter.ae
>
> darkmatter.ae
>
> [image: Linkedin] <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.
>
> *From:* Emad Omara [mailto:emadomara@google.com]
> *Sent:* April 17, 2019 5:12 PM
> *To:* Alexander Sherkin <Alexander.Sherkin@darkmatter.ae>
> *Cc:* mls@ietf.org
> *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 <
> Alexander.Sherkin@darkmatter.ae> 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
>
> [image: cid:image001.png@01D4F5C7.2D8B06D0] <http://www.darkmatter.ae/>
>
>
> 2 Robert Speck Parkway, Suite 1610
> Mississauga ON  L4Z 1H8
> Canada
> *M**T*+1 416 414 7117 <+1%20416%20414%207117>
> *E**M*Alexander.Sherkin@darkmatter.ae
>
> *darkmatter.ae* <http://darkmatter.ae>
>
> [image: Linkedin] <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
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>
>