Re: [MLS] ?==?utf-8?q? Tree of application secrets

Hubert Chathi <hubertc@matrix.org> Tue, 11 August 2020 01:34 UTC

Return-Path: <hubertc@matrix.org>
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 0B0A93A0EA0 for <mls@ietfa.amsl.com>; Mon, 10 Aug 2020 18:34: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 (4096-bit key) header.d=matrix.org
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 FHXneGHcvXam for <mls@ietfa.amsl.com>; Mon, 10 Aug 2020 18:34:02 -0700 (PDT)
Received: from polemos.matrix.org (polemos.matrix.org [94.237.46.156]) (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 A49CA3A0EBA for <mls@ietf.org>; Mon, 10 Aug 2020 18:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=matrix.org; s=polemos; h=Content-Transfer-Encoding:Subject:Message-ID:MIME-Version:To:Cc :Date:From:In-Reply-To:Content-Type:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JKxXTfy/dqDOwayT4gyv5jlojaaOdnn3QAHUwBnkj3s=; b=THdKZYlV0vMXVqOyeHKUYFZ9bf 9pKSEMIgIED+dxkUZHRLV+SFYfnt/2Lxl6xeR6odgjkTvtYf/Ac4r9PGDGt02pnny2cBHlfWvvAWG K09+xD4qq9odg0NrlAzqEnx2x8wl5dttNngy+F/se50qQn29gwgE0h6IHuj74e5eVMeaZpFIY8069 lYMkabLmKkU2lBhAATuUbpmm+CvU+dohzx4OPrsOogF4bJFnVwSoy7U3PvYe1OUZFBtu1EGPJ8lM1 +4c/HquXeGj9C1j62QU23oinLbWfbM02gzorsduKjVouFVqpgHtNnu5IUM1NTBGlYFuvCH/9GeQAs lrrndF4TyCe7jIGHmlGjM/AHHGukbU6Z+6YG10T3A06S0vwQIaYawnRgyLj6b2qiolleDZIiqRf2+ CihNP0tD3ZgIKTybM2iOIbMigbMrUzbYDziyHPA5pQZZEFvZxkF6qfDXrKqbu0TKhV7HT/d7V9F6l V93tWpmU+76gRKo6BQ4jK0xYyiIryachQwNfPEyVsQdFAIqBBU4dpaVMOz7kbl4LE/Nx00FTOFiXV MTHcP47Q0M63dzfkfbaj2dBwVfHdU0qGosK8zbHd9uLOk7Z0K7ABHPIlPOZEJ5Ib3Cn25vUL4xL2C BlYLWu05954q/oVZoMMl08BNg9uP73zoYK74wMGps=;
Received: from [127.0.0.1] (helo=localhost) by polemos.matrix.org with esmtp (Exim 4.89) (envelope-from <hubertc@matrix.org>) id 1k5JAX-0001y2-So; Tue, 11 Aug 2020 01:33:37 +0000
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <CABP-pSSULNagNQdFhPwkSMsQfzfzq7d1HbD+2_KTSDOgSzc6BA@mail.gmail.com>
From: "Hubert Chathi" <hubertc@matrix.org>
X-Forward: 45.58.213.43
Date: Tue, 11 Aug 2020 02:33:37 +0100
Cc: "Messaging Layer Security WG" <mls@ietf.org>
To: "Brendan McMillion" <brendan@cloudflare.com>
MIME-Version: 1.0
Message-ID: <c09-5f31f580-7-1a8b4380@18206122>
User-Agent: SOGoMail 3.2.6
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ZQIo8bav0O21_S5v11pqMUtUI44>
Subject: Re: [MLS] =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__Tree_of_application_se?= =?utf-8?q?crets?=
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, 11 Aug 2020 01:34:05 -0000

Ah, right.  That makes sense.  Thanks for the clarification.

On Monday, August 10, 2020 18:29 EDT, Brendan McMillion <brendan@cloudflare.com> wrote: 
 
> Hey Hubert
> 
> The following section describes the application secrets tree's deletion
> schedule
> <https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html#name-deletion-schedule>.
> Values are deleted from the tree as they're consumed to provide forward
> secrecy. In the flat approach you described, it wouldn't be O(1) to
> generate a leaf, it would be O(n) because when you consume the root node
> you'd have to generate every leaf.
> 
> On Mon, Aug 10, 2020 at 1:27 PM Hubert Chathi <hubertc@matrix.org> wrote:
> 
> > The tree of application secrets (#astree) is used to derive an application
> > secret for each sender.  However, only the leaf nodes are ever used; I
> > don't see the internal nodes being used anywhere, and I don't see that
> > deriving through a tree provides any extra security.  Would it be simpler
> > to just derived the application secret for a sender using their leaf number
> > (e.g. astree_node_[N]_secret = DeriveAppSecret(application_secret, "label",
> > N, 0, Hash.length) using the same DeriveAppSecret as defined in that
> > section)?  This would mean that if you need to derive the application
> > secret for one of two senders, you'd only need to do O(1) work, rather than
> > O(log(n)) work.
> >
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
> >