Re: [MLS] long term identity key rotation suggestion

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Wed, 20 November 2019 09:00 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 A7AEA1208E3 for <mls@ietfa.amsl.com>; Wed, 20 Nov 2019 01:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 AebeIMTLrwTP for <mls@ietfa.amsl.com>; Wed, 20 Nov 2019 01:00:37 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 0535B1208BC for <mls@ietf.org>; Wed, 20 Nov 2019 01:00:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,221,1571695200"; d="scan'208,217";a="327342408"
Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.20]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2019 10:00:21 +0100
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Message-Id: <EDFFB446-9941-4836-9D36-12628E6F2955@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F6AF20C7-1560-412B-A893-522B8E123D3D"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 20 Nov 2019 10:00:19 +0100
In-Reply-To: <MN2PR11MB3901A192266B08604772B91BDB4F0@MN2PR11MB3901.namprd11.prod.outlook.com>
Cc: ML Messaging Layer Security <mls@ietf.org>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
References: <MN2PR11MB3901A192266B08604772B91BDB4F0@MN2PR11MB3901.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/VwzrNH1oMtb8hvwUS9KWqGjhVuk>
Subject: Re: [MLS] long term identity key rotation suggestion
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: Wed, 20 Nov 2019 09:00:40 -0000

Hi Owen,

We’ve had this mechanism in mind for a while now and a few PRs are in the works to
achieve that. The idea is very similar, we are replacing the leaves of the Tree by having
the full ClientInitKeys and are introducing a “Identity” group operation which will replace the
entire ClientInitKey in the leaf, this message being “blessed” by the current signature key.

Aditionally to that, I’ll propose (probably earlier) that we split the term identity key from
the signature key in such a way that the signature used in the protocol are group-specific
and not reused accross groups.

Because authentication is extremely critical and affects basically everything in the protocol,
we want minimal security proof before pushing this PR and we’ll try to discuss it at the interim
in January to see if we can get consensus. : )

Best,
Benjamin


> On Nov 20, 2019, at 9:36 AM, Owen Friel (ofriel) <ofriel@cisco.com>; wrote:
> 
> There is currently no mechanism defined in https://tools.ietf.org/html/draft-ietf-mls-protocol-08 <https://tools.ietf.org/html/draft-ietf-mls-protocol-08> for long term identity key rotation. Richard and I have been thinking about how we could address this and here is a suggestion that could work.
>  
> The genesis of the idea is that as client can Add and Remove other parties from a group, a client with both an existing long term identity key (LTIK) that is in a group, and a new LTIK that is not in the group, could Add the new LTIK to the group, and then the client uses the new LTIK to Remove the old LTIK from the group. Working through that, it quickly collapses into a single Update message.
>  
> It ends up looking something like this (where CIK = ClientInitKey):
>  
> Client starts with:
>  
> LTIK-0
> CIK-0 signed by LTIK-0
> LTIK-0 and CIK-0 public key are in a group LeafNodeInfo.
>  
> Client then:
>  
> Generates new LTIK-1 and interacts with AS to get new LTIK-1 attested/signed.
> Generates CIK-1 and signs it using LTIK-1
> Interacts with DS to get LTIK-1/CIK-1 public keys published.
>  
> Then the client:
>  
> Sends Update Proposal message, signed by LTIK-0, which includes CIK-1, as opposed to just an HPKEPublicKey.
> Updates DirectPath
> Sends Commit message, signed by LTIK-0, which includes new DirectPath
>  
> Receiving clients need to:
>  
> Check that the Update is signed by LTIK-0 and that LTIK-0 is trusted
> Check that CIK-1 is signed by the embedded LTIK-1
> Check that LTIK-1 is trusted
> Update the sender’s LeafNodeInfo with LTIK-1 and CIK-1 public key
>  
> Subsequent messages sent by the client are signed using LTIK-1.
>  
> Thoughts?
> Owen
> _______________________________________________
> MLS mailing list
> MLS@ietf.org <mailto:MLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>