KeyPackage Reuse, Authentication Service #48
Description
The current specification is a little bit lacking on information what to do with key packages and what business rules apply, but from what I understand, I don't think it matches how things should work in MLS.
The important key point missing I think is that key packages are not the equivalent of a public key in OpenPGP or similar. A key package is meant to be used to join a user into a group once, i.e. it is only fit to add you into a single group. After being used, the key package (or parts of it) should be discarded. See RFC 9420 Section 10 and Section 16.8.
The way it currently is described in the specification, it sounds as if the idea is that each client uploads exactly one key package and keeps it there until the device is no longer used. This is definitely not how it's meant to be. Even if the client would immediately replace the key package stored for them, this would still mean that reuse of key packages happen regularly, if the client is added to more than one group while offline.
Further, the design of the AS described in the specification both mischaracterizes what an AS is (it's not to verify the relationship of a key package and a user, but rather to verify credentials) and build upon a key package being persisted.
MLS leaf nodes (which are part of the key package and remain stored in the group state where such key package was added to) include a credential and the public-part of the signing key. The credential is essentially a claim of an identity (e.g. a basic credential could just be acct:[email protected]). The responsibility of the AS is to allow clients to verify that the use of the signing key indicates that the claim in the credential is valid.
One way to implement this and which I believe is the variant you intend to specify here, is to resolve the identity to some server and have the server list all the valid signing keys for such an identity. This however, does not require listing the key packages (or matching the key packages), but really only the signing keys.
Long story short, I think the whole key storage part needs to be revisited. It should consist of two parts:
- A list of public keys that are signing keys for the user, which can be added and removed. Maybe you want to also keep some sort of expiry on those, so that devices that are no longer used can be automatically removed after a time has passed (and if they are still used, they would just regularly move the expiry further in the future) - but that's of course very much optional. The AS is then essentially as described now, except it uses public keys rather than key packages.
- A mechanism for delivery of key packages that is designed to prevent reuse (except for DoS prevention as mentioned in Section 16.8). One reasonably easy way to do this is to have the client upload a set of key packages and when another client requests for a key package to add this user to a chat, pick one from the set randomly or round-robin and then notify the client which key package was handed out so that it will replace the used key package(s) once back online.
Even better would be if you make that key package request authenticated, so that DoS protection can be applied (by limiting the amount of key package requests a client can do) and to include the requester in the was-handed-out notification, so the user can take appropriate action if there's indication of an attack.
PS: Maybe consider taking a look at mimi-protocol. Not necessarily to implement it (which IMO would be amazing), but rather to get an idea what kind of data flows likely are needed or useful and what to consider during protocol design.