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 > >
- [MLS] Blocking Update messages for breaking post-… Alexander Sherkin
- Re: [MLS] Blocking Update messages for breaking p… Emad Omara
- Re: [MLS] Blocking Update messages for breaking p… Alexander Sherkin
- Re: [MLS] Blocking Update messages for breaking p… Emad Omara
- Re: [MLS] Blocking Update messages for breaking p… Alexander Sherkin