Last resort key packages + key package expiry

[richardhuaaa]

No description provided.

[neekolas]

I think there are two remaining tasks here @richardhuaaa @Bren2010.

1. Make the client periodically upload new key packages

WDYT the rules should be @richardhuaaa @Bren2010?

On client instantiation, if last_upload_timestamp > 24 hours ago?

2. Make sure we throw a clear error message when trying to add a member to the group with an expired key package

[richardhuaaa]

My assumption here is that the old key package is invalidated as soon as the new key package is uploaded.

> 24 hours ago makes sense. We could also consider a non-time-based approach, which is to upload a new key package as soon as the old one is 'dirty' - meaning, as soon as it is used to decrypt a welcome.

I believe the property we want (which one-time key packages would have achieved) is that the private key data is deleted from the receiving client as soon as possible after it is consumed (i.e., forward secrecy is achieved as soon as possible after a welcome is received). The non-time-based approach seems to achieve a shorter time window, is more efficient with network resources, as well as requires less book-keeping.

Some other thoughts that apply to both approaches:

1. When invalidating an old key package, the client should probably still keep it for a duration, to handle race conditions (e.g. 1 hour). It's probably important that the client syncs any pending welcomes during this time. This could get messy.
2. Key package expiry actually seems orthogonal to the problem we are trying to solve (both approaches will work even if key packages never expire, same as with one-time key packages). What's important is the refresh interval for uploading new key packages and invalidating old ones. If we are concerned about inactive users dropping messages, or we want to save implementation time, it seems we could just remove or lengthen the expiry.
3. As we are invalidating the old key package as soon as the new one is uploaded, we could consider having the client sign a sequential ID to establish a client-driven ordering. Of course we can still rely on server trust for the ordering today if we don't have the bandwidth for this.

[neekolas]

I like the idea of just rotating any time we receive a Welcome. On board for this approach.

Agreed that we need some sort of grace period before we delete an old key package. Maybe we keep one past KP around on the client? That guarantees that we've synced Welcomes before we delete anything. I'd also be fine with a time-based approach.

In either case I think we'll need to add some bookkeeping on our end. The OpenMLS store doesn't really allow for "list all my key packages" operations, so we'll need to keep track of the KeyPackageRefs in our DB so that we can find the ones to delete.