Re: [MLS] Mandating the expiration of KeyPackages (redux)

[Benjamin Beurdouche <[e-mail]>]

> On 6 Mar 2020, at 21:26, Brendan McMillion <brendan=[e-mail]> wrote:
> 
> Hello mls@
> 
> In PR #275 <https://github.com/mlswg/mls-protocol/pull/275/files>, we started mandating the expiration of KeyPackages. However, the PR also allows applications to set the expiration of the KeyPackage to the maximum value for Last Resort keys -- meaning they never expire.

Well, the previous situation was that there was literally no expiration field.

> I think this is conflating the problem that Last Resort keys solve with something else. Last Resort keys are a solution to DoS attacks, where somebody sends a user a lot of messages in a short period of time, to exhaust their cache of one-time-only keys and prevent anyone else from sending messages to the user. Last Resort keys are not a solution to the problem of the user being offline for an indefinite period of time. Trying to use Last Resort keys in this way can pose a problem for PCS, because if a user is compromised then any of these KPs can be used to “add” the user to the group, when they’re actually adding an adversary.

No... even if you were in my brain when I wrote it, I can assure you, it was not… : )
The goal was to achieve the first step of moving from no expiration to some expiration,
which was striking a balance when some of the editors were at a disagreement.

> It’s tempting to say that the PCS issue is solved by rotating the user’s identity key, as this invalidates all the previous KeyPackages that were never going to expire. However, this implies that the user’s identity key needs to be rotated as often as new KeyPackages would ideally be generated, which could create a substantial burden on the Authentication Service. Practically, I think it’s unlikely that identity keys will really be rotated this often, or that reliable revocation will be implemented by many operators. And finally, the rotation requirement is incompatible with the multitude of signature schemes that don’t require a new credential to be issued to achieve PCS.
> 
> The improvement I proposed in the PR was to remove this guidance, along with modifying the Expiration extension to be a (notBefore, notAfter) pair. Having start and end dates allows everyone to see the total lifetime of a KeyPackage, and enforce that the total lifetime is below some application-defined limit.


I think the design goals should be:
1. Allow and encourage agressive InitKey rotation
2. Don’t have a difference between InitKeys in terms of structure (last resort or not)
3. Don’t break existing products

Both 1. 2. and 3. are already possible in the current design, so the difference
I see are the editorial and the “notBefore” field which I see as a new feature, and I like it.
The PR doesn’t conflict with expiration of InitKeys on signature key rotation either,
so I think it is pretty good.

I agree with it and support this PR.
B.