[MLS] draft-ietf-mls-architecture-04 Review

Divyank Katira <divyank@cis-india.org> Tue, 23 June 2020 13:46 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 25C273A0E16 for <mls@ietfa.amsl.com>; Tue, 23 Jun 2020 06:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 13Yc-oqBflTx for <mls@ietfa.amsl.com>; Tue, 23 Jun 2020 06:46:12 -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 DDDD93A0E12 for <mls@ietf.org>; Tue, 23 Jun 2020 06:46:11 -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 1jnjFY-00067O-Lc for mls@ietf.org; Tue, 23 Jun 2020 15:46:09 +0200
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org 518485834AAAF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1592919968; bh=3TtFGS7dHhdKjrZVIlycLbPiYkLD4mL72CaR9dQ/U2M=; h=From:Mime-Version:Message-Id:Date:To; b=Rzd9NoeVdkzpnqWggYbUz5JtcuqhNLmMyCakxhATmguEGcggYTV9MiuvZKcQqqYks ZObPL0N1k5hD00vsBBWeviOA1zId+398tmKzXAmEA5+H4lfGRnui8v2blcu3wmlYbA J4aEcPe+QOKDhxitHiCJGigTokO+efdklpQQgdFWD2PPXZv7NiINkDH9LFfjiRfS/7 15NuTguEqkoqryuOnHaxeiFW4jPKyFa/mKZF7Itby+ZRpWW5QSqY6uFLM8MM9TLMYz 8Oq6+z+xWJIpdzyZtPql9Ac863Q64ceG+wh7olz7IeaEBKMM5aDBqCfpLsD59B6xuQ U6s+6kqhnMmVw==
From: Divyank Katira <divyank@cis-india.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C11C5DA8-EE4D-4B16-B2A9-97119BD4FB3A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Message-Id: <FC496923-3941-4C9F-8C99-41845A0C694D@cis-india.org>
Date: Tue, 23 Jun 2020 19:16:01 +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: 025acf9a139f050bc01ccdeba87e03e0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/MbAbv2iCcus_djIzlEREI-7OX1w>
Subject: [MLS] draft-ietf-mls-architecture-04 Review
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, 23 Jun 2020 13:46:14 -0000

Hello all,

Thank you for your efforts in developing MLS. Please find my review of draft-ietf-mls-architecture-04 below.

> Section 2.2 Authentication Service
> “It is important to note that this signature keypair might be the identity keypair directly, or a different signature keypair for which the public key has been for example signed by the identity private key. ... <snip> ... This flexibility also comes at the price of a security tradeoff, described in the security considerations, between potential unlinkability of the signature keys across groups and the amount of time required to reinstate authentication and secrecy of messages after the compromise of a device.”

There is a slight inconsistency here. The text mentions a description in the security considerations section about a tradeoff between using different signature keys across groups in place of the long term identity key for unlinkability, and the time it would take to reinstate post-compromise. However, I found no such description there, particularly, in the ‘Client Compromise’ section.

> Section 3.1.5. Privacy
> “A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS.”

This is marked as an open issue, and I agree with the comment in the document that the privacy statements seem strong. While MLS does make reasonable attempts to protect metadata through message padding and encrypting sender information, a service provider may still correlate senders and receivers of a message. A sender could be unmasked through traffic analysis, by using the group identifier in the common case of a group size of two, or through knowledge of group membership in the server fan-out model. I think that this section should acknowledge such practical limitations to the privacy properties of the protocol.

> Section 3.2.1. Connections between Clients and Servers (one-to-one)
> “... the security of MLS will generally survive compromise of the transport layer, so long as identity keys provided by the AS are authenticated at a minimum. However, MLS ciphertext contains the Group Identifier, Epoch number and Content Type that may be used to improve attacks on the privacy of the group.”

This section on transport layer security compromise should also acknowledge that MLS allows certain handshake messages (external proposals, for example) to be sent as ‘MLSPlaintext’ which could reveal information such as group membership, and have a more direct impact on privacy of a group.

I have also submitted a pull request with minor editorial changes here https://github.com/mlswg/mls-architecture/pull/65 <https://github.com/mlswg/mls-architecture/pull/65>

Hope this helps!