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

Alexander Sherkin <Alexander.Sherkin@darkmatter.ae> Wed, 17 April 2019 20:57 UTC

Return-Path: <prvs=003ecf5fe=Alexander.Sherkin@darkmatter.ae>
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 9BAFC120498 for <mls@ietfa.amsl.com>; Wed, 17 Apr 2019 13:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 FfzmQelMehxQ for <mls@ietfa.amsl.com>; Wed, 17 Apr 2019 13:57:56 -0700 (PDT)
Received: from smtpext3.darkmatter.ae (smtpext3.darkmatter.ae [185.180.84.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A6D120605 for <mls@ietf.org>; Wed, 17 Apr 2019 13:57:52 -0700 (PDT)
IronPort-SDR: vCcql553l9xrDEAX2DYzOAl0Z7Yg9PKwHRPrBWBshGqYdpmK1QNr1icQJhLtDOP7R8/++vySW5 3/P/mM1DQrqtE7bkk8aREn/C8RWYe2/d6S0THzNc5xniRram6tKVN74EIwOAAVBOEPlKxnP4gI NqzuQh/r6SKRFnyp7x6WA+GZRZpG7gs+TCE1ZMNq8N9SXfS+1uw9t20BQXiUPnANuROJ8Ha6BT svf8Aq48bqNseJL8bHwY8dssaU+IerEupQKBOTW6mwmVR+6Zb6IbhUhga1C4lSdJ6pKstHd/Kh +Oc=
IronPort-PHdr: 9a23:Wrc6aBSU2KFQiaEmippfB1zgQNpsv+yvbD5Q0YIujvd0So/mwa6zZx2N2/xhgRfzUJnB7Loc0qyK6vmmAjdLuMva+DBaKdoQDkdD0Z1X1yUbQ+e9QXXhK/DrayFoVO9jb3RCu0+BDE5OBczlbEfTqHDhpRQbGxH4KBYnbr+tQt2agMu4zf299IPOaAtUmjW9falyLBKrpgnNq8Uam4RvJrssxhfTrHZFdetayX5oKF+dgh3w4tu88IN5/ylfpv4t69RMXbnmc6g9ULdVECkoP2cp6cPxqBLNVxGP5nwSUmUXlhpHHQ3I5wzkU5nyryX3qPNz1DGVMsPqQ780Xy+i77pwRx/zlCgHLT85/3rJhcF2kalWvQiupx17w47TfYGVKP9zdb7TcN8GWWZMWNtaWipcCY2+coQPFfIMM+ZGoYfgu1sAoxiwBQijC+zz0TJInGP63a8g3ug9DQ3L3gotFM8OvnTOq9X1Mb8fXPyxzKbWwjTMdfVW1irj54jSbxsvvPGMUqxqccrSyEkvER7Og1KMpIzhITyU2f4Cs26G4OV+T+KjkXMpqwFvrTi1xccsi4/Ji5kIxV/e7yV5w4M1KsekSE5nf9GkCoFcuDuEOIZvRM4pXm9muCE/yrIcuJ67ejAHyJAmxx7ZaPyIbZWH4hPlVOqLPTh4g3dldKqjhxe88Eig1vH8Wdeu0FpQsiVFldzMumgQ2BPJ8MiHSf598V292TaTyQ/T8PtILloqmqfdNpUvwaYwm4IOvUjfBCP6hlv6gaCMekk54OSl7/jrbq37qpOALYN4lB/yP6s0lsG9Duk0KAwDU3Sd9O+hzrPs51f5T69PjvAul6nZt43VKtoDq66iBg9Vzp4j6xGiDze6yNgYnWcILFZCeB+fjIjmJVHPIOvhAfihjFWsjClny+rbMbL7GJXNLX3Dn639fbZh9UFc0hA/wspB6J5MC7EBJuz8WlPpudDFEhM1KRK4z/joBdlny48SQ2aCDrOBPKPXq1CI5+YvI+eWZI8SvTbwM+Qo5/rwgn42g1Ade7Sm0oUNaHyiA/pmI1uWYWDvgtcAF2cHpRcxQ/bwiF2BVD5cfWqyX74i6TEhEo6pF5nMSpi3gLOdxCe7AoFWZmdeB1CJFXfobJ6JW/YSZyKOLM9tiDsEVaKuS9xp6Rb7/gr+0JJmI/bavCoCutirgN1x/MXSmA08sztuAJLO/XuKSjRdmm4YTjk60bo3mkxw0FSC1+AsqvhVBdVV6/5TFDw6OITfzupSB9noWQfIYsuEUhCvT4P1UnkKUtstzopWMA5GENK4g0Wb0g==
X-IPAS-Result: A2l6DgB7krdc/1oB4ApjAx4BBgcGgWWBDwFXgRKBLAqEBJhASpJAgkqBKzwLARcQDIFJgnUZhiI4EwEDAQEBAwEBAQECAQEBAYEFAQuCOiIYBHwLBAEBAQEBAQEBASQBAQEBAQEBAQEBAQEBARsCMwgMNQEdCiYTChsBFRABAQEfAwIEBRAPIBIBBBIBCAaDFYIXqlqBL4VHhFgQgTKEYV2DQnYQgxs/h0ICgS4BEgE2CiaCQ4JXBIpWASWCLYQ6h2eEToglBwKCCFOEPAEqUYlngiQjggldhUCMV4txgR6ER0qQBoEHWg8IMxqDXwmCEReBAQECRYIDilNyji+BIoEhAQE
X-IronPort-AV: E=Sophos;i="5.60,363,1549915200"; d="png'150?scan'150,208,217,150";a="3103369"
Received: from ForcepointDLP ([10.224.1.90]) by keys-ext2.darkmatter.ae (PGP Universal service); Thu, 18 Apr 2019 00:57:47 +0400
X-PGP-Universal: processed; by keys-ext2.darkmatter.ae on Thu, 18 Apr 2019 00:57:47 +0400
Received: from ActiveEmail (ActiveEmail [127.0.0.1]) by ActiveEmail.localdomain (Service) with ESMTP id C27741800094 for <mls@ietf.org>; Thu, 18 Apr 2019 00:54:26 +0400 (+04)
Received: from email.darkmatter.ae (adkdcsvmc002.darkmatter.uae [10.224.74.12]) by ActiveEmail.localdomain (Service) with ESMTPS id A952F1800093 for <mls@ietf.org>; Thu, 18 Apr 2019 00:54:26 +0400 (+04)
From: Alexander Sherkin <Alexander.Sherkin@darkmatter.ae>
To: "mls@ietf.org" <mls@ietf.org>
Thread-Topic: Blocking Update messages for breaking post-compromise security
Thread-Index: AdT1X6+b0ZittmB8TOOUBJ3Ui56HyA==
Date: Wed, 17 Apr 2019 20:57:46 +0000
Message-ID: <526edb2c61bb48c4aa34f20ad91db0f2@darkmatter.ae>
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.224.74.90]
x-exclaimer-md-config: 77ff947c-8af8-48f1-8d81-f67dcf75dbee
MIME-Version: 1.0
Content-Language: en-US
Content-Type: multipart/related; boundary="_006_526edb2c61bb48c4aa34f20ad91db0f2darkmatterae_"; type="multipart/alternative"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ZcLijrPe-iLVU2nkbyzp9XXyqNU>
Subject: [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 20:58:03 -0000

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:imageeee358.PNG@2312e51f.41b90803]<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:Alexander.Sherkin@darkmatter.ae>

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.