[MLS] All commits = external commit?

Joel Alwen <jalwen@wickr.com> Tue, 06 October 2020 16:38 UTC

Return-Path: <jalwen@wickr.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 820503A0CCE for <mls@ietfa.amsl.com>; Tue, 6 Oct 2020 09:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.20150623.gappssmtp.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 OKqxO8GgPvyU for <mls@ietfa.amsl.com>; Tue, 6 Oct 2020 09:38:53 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 A5D4B3A0B23 for <mls@ietf.org>; Tue, 6 Oct 2020 09:38:53 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id p13so8324792edi.7 for <mls@ietf.org>; Tue, 06 Oct 2020 09:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=uR1Y9++/lNn3PH0ZhggaLIPW8bJri6GciTnYVxWLDn8=; b=1+fmEuLgrNKVD8HPZWimZRCTnoE6TcAlcQUW+oQlg6q6F6Gw1kQyrbCU8/XQr/Mog8 kqYz2AtuZZCvZTuXnc7yjqCmGX/mNijogUAqbj0U29iY4C281bWOqbndNN52gW9ZnMuh E9b7iMisyARE49bwVgXJhNIF/MSpFo+8c1FNwdYal5Ku12xHWcrg3bex1vVj/28/gRtF HM5dXItXICX/f+R6v5aJZNqSh/DcKVZjHriEhjEoPACWT9Q6U/G1F21TKCMqrAg2F67Z fF7qPw+hOd0sLPvnl6gzpMydOAXXn4tejgRW7qNYgehkSnmTYAiWiOlj6Gjnn7Gb5j6k Ej7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=uR1Y9++/lNn3PH0ZhggaLIPW8bJri6GciTnYVxWLDn8=; b=ZUJsyqQiuXJZ1+OybWoZrtlZ77tAQcMUnSAn45XoJuZHYkocGj4tEB43538M93ZWFN hlc4twSOGOSpEIWxXtyGzr8WcFOS8uZTmtcYiNs1M5OebhvGaC25nPnK2pdCZc7NBAQD VbJQ4BQZd6OYdkgOZdf3Y2W3vAqEKRoSlpFbwhKga1Qik2smOoBo+tLT8fcaD6yzNxLx Q+vU24yoFr+ysElBPUiH3Ys1ihF6zgb7IK+drja5Vxa8hMi/EiWOwtKNaJVHB7kSuJo/ HjM40MDshilex681xpO9K7kYxrU4X8kSncnsLt6wHI22tzKTh3Uy+YTXRUCTUrP9KnaC Txfw==
X-Gm-Message-State: AOAM5321UeXggut376Cq9M3kh9fUeGXQD1cgPhIS/9D9OgzJZpE0tUvz MUjwspvcLch+tPCxh7hViaOH29MPXTJTwKDP
X-Google-Smtp-Source: ABdhPJyPv35KL/qApjeniQpCT+Ipz0afwt9bdvjwKVp+MZEuPFLhBeNnsYzMtTccZd7/QFUo7q09rw==
X-Received: by 2002:a05:6402:b68:: with SMTP id cb8mr6735939edb.350.1602002331659; Tue, 06 Oct 2020 09:38:51 -0700 (PDT)
Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id v2sm2493779ejh.57.2020.10.06.09.38.50 for <mls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 09:38:50 -0700 (PDT)
To: Messaging Layer Security WG <mls@ietf.org>
From: Joel Alwen <jalwen@wickr.com>
Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw==
Message-ID: <ceb4e95a-09b7-c4cb-cd8f-50641b605fbf@wickr.com>
Date: Tue, 6 Oct 2020 18:38:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/QF7WHKDnY6bADRcLZkHWnZ1rJx8>
Subject: [MLS] All commits = external commit?
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: Tue, 06 Oct 2020 16:38:56 -0000

Hey people,

To follow up on the discussion at the end of the Interim about whether to use
the new "asymmetric external commit" (AEC) mechanism for internal commits I
wanted to summarize my thoughts here. For brevity let SIC be our current
"symmetric internal commit" mechanism.

- AEC requires extra asymmetric crypto operations (both for committer and
receiver) compared to SIC which I think we should avoid if we can, even at the
cost of some code complexity.

- AEC doesn't ensure the committer knows the old epoch's key schedule. This can
play a deciding role in several types of attacks.

Consider this execution:

1. Alice is in a group. Her state leaks (including her signining key).
2. Alice commits (to arbitrary propal).

At this point, the adversary can still forge a new AEC from Alice but not an SIC.

Worse, step 2 could have instead been "Alice sends an update proposal replacing
her leaf HPKE but keeping the her sig keys (e.g. because new credentials are
costly to come by). Someone commits to the new proposal." At this point I'd
expect PCS to have kicked in for Alice (as it does when using SIC). But not for
AECs since Alice's signing key is all thats needed to forge a new AEC.

I think it is not worth weakening security this way if we dont have to.
(Especially, since in some deployments external commits may not be a supported
feature at all.)

- As for what may or may not be displaid to users, that's really up to the
implementation. IMO our goal should be to make the protocol as secure as we can
subject to reasonable costs. Which aspects of the resulting security properties
are ultimately communicated to users should, in principle, be left up to
implementations. That means we shouldn't be designing away security features
only because we think they might be hard to communicate. (Nor does it seem that
inconceivable to me that some implementation may end up explicitly signaling
whether a commit was external vs internal.)

- Joël