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

Emad Omara <emadomara@google.com> Wed, 17 April 2019 21:12 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 D84BB120075 for <mls@ietfa.amsl.com>; Wed, 17 Apr 2019 14:12:01 -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 WIXYpO52cWWO for <mls@ietfa.amsl.com>; Wed, 17 Apr 2019 14:12:00 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 7F9C012002F for <mls@ietf.org>; Wed, 17 Apr 2019 14:11:59 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id r4so150514wrq.8 for <mls@ietf.org>; Wed, 17 Apr 2019 14:11:59 -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=IrDUpH9nlzzSJ/xpEDrgFSn/gB03Eufymf7Y/6mP5QQ=; b=VjuJP2sBTxdUlDDjog4jHYniVS+p27SbiJRmcVQW6Xx2GglAUbM8PAsxWb+kzOodWt 2DlvQtUOnT25rsPQ7dTS+wxIZAs/+1ODzJqSUoNwfZ/I5t1+A3ry+zvji0rwtWJcEKzw sDM72zzWWZQTesU7lOfCbb/L4ic308TQSgfTTbkk138f185Vgx899nw/+blMre9DTCAG SF9fTB7Se/FVJ1k8vfsWJX5QsO94CBgpmfo94qOVlesp+tRt/z3BotXLbCBgms00SAyR RjAzUofo0cu9vz9fFiL0gDH1PQLXVMZ919YtcMdqNPZFeBuM56EFI2ck29KXd+MxEzQG mABw==
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=IrDUpH9nlzzSJ/xpEDrgFSn/gB03Eufymf7Y/6mP5QQ=; b=etBWwV0Dndv9MHi4Jw3HrP/Tw3a3eVUFA7BxvN0BaAH6k5gTf8bbHne4P2dy+cx3m8 Z2fXjZ139EqfLmGxYexwbFPyTC6Dbol6rX0s8z5Nm1vvF2Xi/ALCaBMF2waSWMqDZTSn 2CEl/gVVGbgSovBNOhItQcwQ65TVMp+KopAaudmVpdeKTeoLblSQn3/TvupBt7sc/kwQ rVVhMN/L/o3AQZNmvNREwR7rXB30LEweeWXtthgK7NLI8z05AWHLxAvgb2wM9oWa1bHJ ck6TxBTx4rpsV6taRYKXdORCPs9KaO+UmCELF7eeVGY/JhtmaEVptb2R0NqIQDmFP8gG VIog==
X-Gm-Message-State: APjAAAVx0vMmzMvOqsCB+KpZIMmBi1QdcCRtB/N+Qjju2QwwZN9MrvXf 7dFE645K7X6Q/GgTUB0UOl7Q3b6n2L0VPXtu6Q2xzcc=
X-Google-Smtp-Source: APXvYqwkTfvZ/YjmspK84l1m6tiHvROAtOtUKRL7Zei/YVifsJatIjT2KDdY40oKlZ34zrYDhVt75NcO77jDsaIobZA=
X-Received: by 2002:adf:ff88:: with SMTP id j8mr58349395wrr.1.1555535517368; Wed, 17 Apr 2019 14:11:57 -0700 (PDT)
MIME-Version: 1.0
References: <526edb2c61bb48c4aa34f20ad91db0f2@darkmatter.ae>
In-Reply-To: <526edb2c61bb48c4aa34f20ad91db0f2@darkmatter.ae>
From: Emad Omara <emadomara@google.com>
Date: Wed, 17 Apr 2019 14:11:46 -0700
Message-ID: <CAHo7dC8qTkdFn8D4QoD5eequ-WvLx2U7wabDuDHEY0Tbm7QPUA@mail.gmail.com>
To: Alexander Sherkin <Alexander.Sherkin@darkmatter.ae>
Cc: "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/related; boundary="000000000000f3d5620586c055cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/vUNC5uFlU-aOZTb7Iy6Bpr-bc7A>
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: Wed, 17 Apr 2019 21:12:02 -0000

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
>
> <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.
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>