[MLS] External Proposals Guardrails

Divyank Katira <divyank@cis-india.org> Tue, 14 July 2020 06:36 UTC

Return-Path: <divyank@cis-india.org>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 39EDD3A114C for <mls@ietfa.amsl.com>; Mon, 13 Jul 2020 23:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cis-india.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id u5PjVipiDsRI for <mls@ietfa.amsl.com>; Mon, 13 Jul 2020 23:36:11 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl []) (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 D3E883A114A for <mls@ietf.org>; Mon, 13 Jul 2020 23:36:10 -0700 (PDT)
Received: from smtp.greenhost.nl ([]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <divyank@cis-india.org>) id 1jvEXt-0005H3-CJ for mls@ietf.org; Tue, 14 Jul 2020 08:36:08 +0200
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org E0DAD581C006C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1594708564; bh=YkKM/XkDgH6+8MA9XZ+sc2qguGmJ1xeaYOB0YKKig50=; h=From:Mime-Version:Message-Id:Date:To; b=YkURxGU1+PNXontCeGqZvNXIKL+yBN+v0TgE4bjzBdMgdDYpG+40P9ov2iZg/8l0d 07+Pio4EAALtTA/TdA6XCd2XUVY2BYYzWmpbSbK3iC0fRMRQlgewWIweJy5raxUdee y4Eu9HtGZMCOtqLb6N21yqHwE9GKTtxhvwVWBDLYZUByUsNkzR7rvwLeal4yI7wy9Y /L4nZMFscl8db3dGmcQVXZefMEzjGj2Ej1YRqTgtVl4/rRu9teImF3p1XOeE/VZJ1d M1mi9C0WYV7568efBKqdweqiUcaFynHWvTqsPLw8n8lCqv3jpw/PV4JDipAzAu6M63 m8zwzVIfvkMSg==
From: Divyank Katira <divyank@cis-india.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD89881B-4E6F-4162-928D-3F9306AE7231"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Message-Id: <E9AB16A9-285D-4558-9821-A5EC270E26AF@cis-india.org>
Date: Tue, 14 Jul 2020 12:05:54 +0530
To: mls@ietf.org
X-Mailer: Apple Mail (2.3601.0.10)
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 9484ae446d4f83cee8bf28db5146d16c
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/9wgOSESTkXszlf0QWfEoErnifRk>
Subject: [MLS] External Proposals Guardrails
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, 14 Jul 2020 06:36:13 -0000


A poorly designed implementation of external proposals could break the end-to-end encryption provided by MLS. A compromised server could arbitrarily add and remove group participants. While such tampering would be visible in the chat transcript, the utility of manual verification is diminished in large groups like the ones MLS enables.

I suggest two changes to nudge application developers towards a more secure design:

 - On the server side, given that the user/identity recovery cases that external proposals aim to address fall under the authentication service's purview, the initiation of such proposals can be constrained to the authentication service and not any preconfigured entity. This reduces trust on the delivery service provider in cases where a custom identity provider/SSO is used. This also fits better in the security considerations in the architecture document where authentication service compromise and delivery service compromise are treated differently, with the former leading to break of confidentiality, and the latter leading to denial of service.

 - On the client side, the protocol should signal to application developers that external proposals should be handled differently from other proposals. For example, an update proposal is a routine operation that can be committed automatically whereas an external proposal should require consent/manual consideration before commit.

I am happy to make concrete suggestions to the text if this sounds like a good idea.