Re: [MLS] Key Schedule, ProposalOrRef objects, Group splitting attack

Raphael Robert <ietf@raphaelrobert.com> Tue, 08 June 2021 19:01 UTC

Return-Path: <ietf@raphaelrobert.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 95BE43A3A96 for <mls@ietfa.amsl.com>; Tue, 8 Jun 2021 12:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=raphaelrobert.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 N1ykS4R-FOea for <mls@ietfa.amsl.com>; Tue, 8 Jun 2021 12:01:00 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 8F02A3A3AAD for <mls@ietf.org>; Tue, 8 Jun 2021 12:00:53 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id l2so22752517wrw.6 for <mls@ietf.org>; Tue, 08 Jun 2021 12:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QO2vzz/3FqURT6WSxWxLxubX1OjtGLR35mn63kKhHmw=; b=qPIS+BcaIrxPAGPl9E2BKleyyI0dQyAa7n7A59yQsDBeboSB669RZzMJmOM8ZbFpvz jL7RWnbuaf5uicvAriCQyI+V8IpG01rinOglcL57vrOmnGVfxlqAMWq4m51CGoWC2a4B bQjvN/ExjT0zUrGaux3ShJWAJY0OKRirYdVWw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QO2vzz/3FqURT6WSxWxLxubX1OjtGLR35mn63kKhHmw=; b=bz13MBXm3jG2npUI+5bxNkhsCaB4LEcsEY7A8mJSfSyOBm81j53Jo8+zXR/7VN8CJz gT05SdYlErI7BL02u2GeN6msbMK77R8dMzRaVdWjy/u39a+GpkebmNmxyEEMHlNsN7Vu M9KDTSQ59aCSkBRcP4MDG7VUMObm8wQef/VrgVm+ZSD/ChN+LnGKCpxuQOzDG99KBl03 r1Ysb/9kBYlIUAqYS9Cw6AAOzgeiVAyDEVseHjAIJj46Ow0Y4DStzXzGQqFpDKz/vyfL JC9l2BjoaPgCacZynX+cWLBQnRGhUUn98ezmOYOhjYGVCFe8/4JoMBS1Z0cdrG2QRflT fqpA==
X-Gm-Message-State: AOAM533dH3oXu22OY8tRlLfWre7/dSVg6QcvoIYsae7QCoE230Jg44aH gFFQMSyFS7njl8K0gTLWlle4nw==
X-Google-Smtp-Source: ABdhPJwOC7/dXCAb98s6G6iQbO+L21ARlYvfXMWH+B62H2Mm2SZsUWtqXL8NcLngHfQzHRWCgYBNmg==
X-Received: by 2002:adf:f805:: with SMTP id s5mr23733079wrp.231.1623178848676; Tue, 08 Jun 2021 12:00:48 -0700 (PDT)
Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id s1sm3827140wmj.8.2021.06.08.12.00.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jun 2021 12:00:48 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Raphael Robert <ietf@raphaelrobert.com>
In-Reply-To: <CAHvbzjJ9fXseMG6T+bJj4oVxfa3C5FCb73aPDeR04sfuE=accA@mail.gmail.com>
Date: Tue, 8 Jun 2021 21:00:46 +0200
Cc: mls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D74C1ED2-CE12-4991-B5B1-6DA7EDD7ABC8@raphaelrobert.com>
References: <CAHvbzjJ9fXseMG6T+bJj4oVxfa3C5FCb73aPDeR04sfuE=accA@mail.gmail.com>
To: Tijana Klimovic <tijana.klimovic97@gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/dy4tnBh7syTqACOQfwth782HSp8>
Subject: Re: [MLS] Key Schedule, ProposalOrRef objects, Group splitting attack
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, 08 Jun 2021 19:01:12 -0000

Here’s a partial answer:

> On 8. Jun 2021, at 11:16, Tijana Klimovic <tijana.klimovic97@gmail.com> wrote:
> 
> Hello,
> 
> I had a few questions about different parts of the specification.
> 
> Firstly, I wanted to ask about the motivation behind the Key Schedule being what it is, namely a sequence alternating between KDF.Extract and KDF.Expand. Why couldn't it be just a single KDF.Extract followed by a single KDF.Expand, to form an actual key derivation function, and then derive the different keys by providing the appropriate context? 
> 
> Furthermore I am not sure why the KDF.Expand is used at all here since the length parameter provided is KDF.Nh which from the specification is supposed to be: "The value KDF.Nh is the size of an output from KDF.Extract, in bytes". Therefore, the KDF Expands used by the scheme don't really expand the pseudorandom key given by the KDF.Extract to have a bigger length.

I’ll let someone else comment on the above.

> 
> I am not sure why we use a ProposalOrRef type. And why only proposals sent by the commiter are included by value and all others are hashes of the MLSPlaintext containing proposals sent by members different from the commiter. 

Proposals are handshake messages in their own right and are distributed between members within an epoch. At the end of an epoch someone sends a Commit that references the proposals with a commit hash. 
To make things easier for members who immediately want to commit to a proposal, inline proposals are also supported so that members can do all of it in one message. That’s all there is to it.

In earlier versions of MLS, handshake messages were always committing. Introducing the proposal-commit scheme brought some more flexibility in general. Now there can be proposals from externals as well, or you can propose to remove yourself from the group (which impossible before, someone else had to remove you).

> 
> Lastly, I haven't managed to find where the specification tackles the problem of the group splitting attack. Namely, if we for example have a group of 5 clients, the attacker can split the group state into two group states, by making sure that any message (proposal, commit, application) originating from client 1,2,3 is delivered to only client 1,2,3 only and that similarily any message originating from clients 4,5 are only delivered to clients 4,5. 

If the Delivery Service decides to route messages this way, there is not much you can do about it as a client. The AppAck extension helps to detect some of the dropped messages, but at the end of the day you have to trust the DS to not do a DoS attack on clients. The protocol cannot fix that problem.
Of course you could try to mitigate this out-of-band, for example you could have a mechanism where members can regularly compare the authentication secrets or some other value exported from the exporter.

Raphael

> 
> Many thanks.
> Tijana Klimovic
> 
> 
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls