Re: [MLS] long term identity key rotation suggestion

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>