-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop support for per-task HPKE configs #2147
Comments
Dupe of #1641, I'll let this issue supersede that one. |
We have decided to move forward with obsoleting per-task HPKE keys and fully adopting global HPKE keys. |
Some notes: We already have support for global keys for the taskprov use case. Functionality should already be present for using these keys. Janus also refreshes its internal cache of these keys every 30 minutes. We'll need some tweaks to remove The main missing functionality is that keys currently need to be manually provisioned. This is a non-starter for normal deployments of Janus, of which we run several. We also need to consider that BYOH deployments probably don't want to have to worry about key management. We need a subprocess |
This can be accomplished by having For BYOH use cases where we're supplying an all-in-one binary, the key rotator task should be started before the HPKE cache task. The key rotator should run a sweep immediately on creation. I didn't really like the "cache always invalid unless one key is active" strategy because the cache logic seems more complicated. |
I've sketched out this logic for the key rotator (may have errors, let me know if anything stands out as wrong). Configuration: struct Options {
/// How often to run the key rotator, in seconds
pub frequency_s: u64,
pub hpke: HpkeOptions,
}
struct HpkeOptions {
// (these can be named better)
/// How long to wait before promoting a keypair from PENDING to ACTIVE. This should correlate to
/// how often Janus updates its global HPKE cache, i.e. 30 minutes
pub pending_to_active_s: u64,
/// How long until an active key should be considered expired, i.e. the age of an HPKE key
pub active_to_expired_s: u64,
/// How long an expired key should be kept around. This should correlate to how long clients are
/// expected to cache an HPKE key.
pub expired_to_deleted_s: u64,
/// A list of ciphersuites to ensure have an active HPKE keypair. Can be multiple, if we want
/// to provide support for multiple ciphersuites, otherwise it can just be whatever we want.
pub ciphers: Vec<HpkeCiphersuite>,
}
struct HpkeCiphersuite(KEM, KDF, AEAM); Key rotator logic:
The HPKE ID is chosen at random, non-conflicting with any IDs currently in the table. It's possible to paint ourselves into a corner e.g. given too many ciphersuites, too long of expiration relative to HPKE keypair age, so it's important to choose the right parameters to avoid running out of u8 space. Age of the key and the time of its state changes are tracked by the extant Note we take an |
|
Supports #2147. Introduces the `key_rotator`, which is a utility for managing the lifecycle of global HPKE keys. It will bootstrap keys, and rotate them according to the rotation policy in the config. Keys are unique by their HPKE ciphersuite. For each ciphersuite, a key is run through the pending->active->expired->deleted lifecycle. It is permissive of some manual operator changes, e.g. if a manual key rotation needs to be executed through janus_cli or the aggregator API. In this iteration, it runs as a standalone binary for use in a cronjob. It is suitable for deployment in our environments, including taskprov ones. A future PR will add support for BYOH deployments by letting the `aggregator` process run the key rotator.
Janus changes are complete. Remaining work in this issue is taking a breaking change to remove per-task HPKE keys, in the next breaking change windows. I've unassigned this for now to keep my queue clear, we can pick it up again whenever we're ready to take some breaking changes. |
We are considering dropping support for per-task HPKE configs to simplify. Note that this will have an impact on a number of unit tests. Global HPKE configs currently can only be set up via the aggregator API, so we may need to make the aggregator API required instead of optional, provide another means to set up a global keypair, or do so automatically on first boot.
The text was updated successfully, but these errors were encountered: