Discussion of TAP 8: Key rotation and explicit self-revocation

[vladimir-v-diaz]

TAP 8 proposal is available at https://github.com/theupdateframework/taps/blob/master/tap8.md

Pull requests related to TAP 8:
#20

Discussion of TAP 8 on the TUF mailing list:
https://groups.google.com/d/msg/theupdateframework/Yj1z3PkMRZc/n8wXM4VZBgAJ

[vladimir-v-diaz]

Hi, @hannesm.

I came across an old comment of yours on the issue discussion for TAP 3 (multi-role delegations).
In the comment you say that a naming mechanism is still needed for TAP 8 (key rotation). Have you found a solution yet? Is there anything else blocking TAP 8?

(I'm just checking in on the status of TAP 8)

[hannesm]

It looks like GitHub ate my email; yes, I'm working on a revision of TAP8 - unfortunately not yet done, but hopefully by the end of this week. I'll open a PR then and let's discuss in that how to move forward. Sorry for the delay.

[vladimir-v-diaz]

No problem!

Thanks, and we're looking forward to TAP 8 revision.

[vladimir-v-diaz]

@hannesm

@JustinCappos asked about TAP 8 during a recent meeting. He was wondering if you've come across any potential issues with TAP 8 while implementing it.

[hannesm]

@vladimir-v-diaz due to other projects, my implementation of tuf + tap8 is only progressing slowly (only doing this in my spare time, working on other projects for funding). so far I have basic tuf nearly finished (in OCaml), and will work over the summer on finalising tuf+tap8. I'll get back to tap8 once implemented, sorry for the delay.

[awwad]

I think this is a good and wise feature add. I was reviewing @mnm678's TUF PR draft implementing TAP 8 and combed through TAP 8 and chatted with Marina a bit. I think that there are some conceptual issues and a few clarifications that should be made. I'm going to stick to only the two bigger conceptual points for this post:

Root Key Rotation Efficiency Improvement

In the course of the client's traversing the path from the currently trusted root file to the most recent root file, I'm not yet convinced that it's okay to only fetch root files that include key/threshold changes for the root keys:
There are settings that change in the root file, consistent-snapshots and spec-version, that might affect the way future root files are interpreted and therefore their validity or the impact of their production. (Consistent snapshots probably doesn't? Haven't thought through it. Spec version certainly could.)
The fact that you always validate root version 10 using root version 9 could matter; even if the keys and threshold are the same, some change to the spec version could change whether or not root version 10 looks valid from root version 8 vs root version 9. In one direction (10 looks invalid from 8, 10 looks valid from 9), this can be resolved by, if an error is encountered, grabbing an intervening root file. In the other direction, (10 looks valid from 8, looks invalid from 9), this cannot be resolved and is a security issue. (You could say that security-impacting new root versions should always include a key change, but that seems like a backward sort of policy.)
I could be off here. Perhaps it's wrong to be concerned about behavioral changes when the spec shifts? (What do we do with old root versions and the clients still using them?) Still, a complication to consider, and the efficiency gain is small.

TAP 3 Interoperability

I think that the particular (additional) TAP 3 interoperability advertised is a little too ambitious -- too complex in code and in concept -- and so probably inadvisable. Imagine that role X delegates to two roles A and B (with two thresholds and two key sets). Which of the following behaviors make sense?

• (IMO Yes) -- A threshold of the keys that X delegates to (associated with role A) could rotate the keys currently expected of role A in the delegation from X. (i.e. TAP 8 deals with individual delegations)
• (IMO No) -- A threshold of the keys A expects of X plus a threshold of the keys A expects of Y could together alter the keys expected / structure of the whole multi-role delegation, using a rotate file whose name identifies these key relationships. (Note that among the issues is the fact that the semantics of the existing rotate file ID formula (hash(k1.k2.k3)) become ambiguous, and collisions would be a problem -- [1 in [k1] + 2 in [k2, k3] vs 2 in [k1, k2, k3], etc.)

Related to the conceptual complexity, it's worth noting that the code to do the second bullet point would mangle the natural structure that exists currently, I think (process a role, move to its delegations). Just knowing what rotate filename to look for in the multi-role case is complicated here, because the keyids in a multi-role delegation to roles B+C may be changed by changes to the keyids for B.

(That said, abstractly: this extra type of multi-role rotation is a feature that hints at the possible value of further reducing the significance of roles in favor of key sets. It's possible that that feature (and possibly TAP 3 and other properties of TUF) would make more sense with a further diminishment of the role of "roles" vs delegations. If there's room to consider something like that, maybe the proposed TAP 3 multi-role rotation would make more sense. Food for thought for someday.)

[mnm678]

After talking with @JustinCappos and @awwad , we found that there are two categories of use cases that TAP 8 is trying to address.

The first (role rotation) involves a threshold of keys from a role rotating the set of keys for that role. This includes the role adding new keys (think adding a new developer to the team) as well as removing a key, changing a key, or changing the threshold.

The second (individual key rotation) involves rotating an individual key (as for key revocation) everywhere that that key is used.

Unfortunately, due to issues with ordering and naming, I do not think it is possible to include both of these features without some major spec changes. Because rotate files are named using keyids, changing keyids with either of the above methods would make it impossible to determine if the other type of rotation is happening elsewhere.

Either of these options would provide some useful features, but I think that the first covers more of the use cases discussed in the TAP. The second case could be achieved using role rotation if the key owner coordinated with all of their associated roles (or could be done individually for any roles with a threshold of 1).

However, a case could be made for expediting individual key rotation in the case of a compromised key. This process would be faster with the second option.

@hannesm Any thoughts about which option we should implement?

[JustinCappos]

@mnm678, Can you describe in a bit more detail here? Perhaps an example would help...

…

On Wed, Sep 12, 2018 at 12:10 PM mnm678 ***@***.***> wrote: After talking with @JustinCappos <https://github.com/JustinCappos> and @awwad <https://github.com/awwad> , we found that there are two categories of use cases that TAP 8 is trying to address. The first (role rotation) involves a threshold of keys from a role rotating the set of keys for that role. This includes the role adding new keys (think adding a new developer to the team) as well as removing a key, changing a key, or changing the threshold. The second (individual key rotation) involves rotating an individual key (as for key revocation) everywhere that that key is used. Unfortunately, due to issues with ordering and naming, I do not think it is possible to include both of these features without some major spec changes. Because rotate files are named using keyids, changing keyids with either of the above methods would make it impossible to determine if the other type of rotation is happening elsewhere. Either of these options would provide some useful features, but I think that the first covers more of the use cases discussed in the TAP. The second case could be achieved using role rotation if the key owner coordinated with all of their associated roles (or could be done individually for any roles with a threshold of 1). However, a case could be made for expediting individual key rotation in the case of a compromised key. This process would be faster with the second option. @hannesm <https://github.com/hannesm> Any thoughts about which option we should implement? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0XD3nXfZ2X0VuX3iNY_MTf_m0CirGsks5uaTH7gaJpZM4NsGtG> .

[mnm678]

Sure, here are some example scenarios for role vs key rotation.

For role rotation, say there's a developer role that has 3 developers who each have a key (A, B, and C) associated with the role with a threshold of 2 keys. A and B would be able to sign a rotate file that adds D to the role, leaving the threshold at 2. The role would then have 4 keys (A, B, C, D) and a threshold of 2. Using this method, a threshold of keys in the role can make any changes to the key/threshold makeup of the role without the delegator needing to sign a new file. This method could also be used for key rotation/revocation. If B wanted to change their key to B2, they could get together with A to sign a rotate file that includes keys A, B2, C, and D. However, if B's key was also used as part of the testing role, B would remain a valid key in that role unless an additional rotate file was created for the testing role.

For key rotation, if C wanted to change their key (possible compromise, etc) they would sign a rotate file with the new key C2. This would then have any role that formerly trusted C trust C2 instead. In this method, a key can make changes to itself (or self revoke by creating a cycle) but any changes to roles would have to come from the delegator.

These are both useful features, but a problem arises when trying to implement both. If C rotated its key to C2 using key rotation, a file specifying that A, B, C should be changed to A, B, C, D using role rotation would no longer be found as the system would look for a file changing A, B, C2 (rotate filename are role.rotate.ID where ID=sha256(keys.threshold)). Removing the keys from the filename would create some confusion as to when various rotate files are valid and make cycle detection more challenging. So as far as I can tell this leaves us with picking either role rotation or key rotation.

[awwad]

As a further note: the TAP 3 Interoperability comment I made above pertains to the role/keyset-rotation feature, which is implicit in the TAP as it exists currently, and the current "Interoperability with TAP 3" section.

[hannesm]

thanks for your comments.

• root file rotations - spec-version / consistent snapshots: I wasn't able to find any documentation how TUF clients should behave if spec versions are modified; similarly I couldn't find any required behaviour when consistent snapshots changes in the root file. Could you point me to documentation? the only snippet I could find in tuf-spec is that spec-version should be compared to match either directly or same major version. I couldn't even find any monotonicity requirement for spec-version - can a root file version 8 with spec-version 1.3 be succeeded by a root file version 0 with spec-version 1.2? how do existing clients deal with this situation?
  I agree that if these two values are expected to be modified during the lifetime of a repository, they should be handled well. An idea in my mind would be to include these in the hash of the rotate root filename, i.e. there'll be the demand of a rotation when you modify these variables.

• TAP3 / multi-role delegations
  this is tough, I also ran into some (not yet finally resolved) issues where to store the signatures, esp. when I want to allow a rotation of C to threshold of 2 [C1;C2;C3] (and how multi-role delegations work afterwards). but what is the actual trouble here for python-TUF? shouldn't the verification algorithm see the above mentioned rotation from 2 [A;B;C] to 2 [A;B;C;D], and then look for signatures (assuming that B and C2 signed): first check A, no signature, then B, valid signature, then C, find the rotation, use the public key C2 instead, and consider that valid!?

[mnm678]

A couple more thoughts:

root file rotation - An option would be to include the spec-version in the root rotate filename, but I’m not sure that is needed. I think a change in the root file’s spec-version or consistent-snapshots is a separate issue that goes beyond this tap. These values could also be changed in a normal root file update and cause inconsistencies. However, TAP8 will introduce a non backwards compatible spec change, so I’ll look more into this issue and how people could update to using TAP8 for root file rotation.

TAP 3 - I think the tricky part would be how to find the rotate file. If there’s a delegation to roles [A, B, C] which have keys [A1, A2], [B1, B2], [C1, C2]. Using a combination of keyids to find the rotate file wouldn’t work if A, B, or C did an individual rotation, so we would need to define a different naming scheme for the rotate file for the multi-role delegation (it would need to include at least the role threshold and role names). This would rely on role names being used as identifiers for the rotate file which brings up some issues with overlapping role names.

Additionally, I made a couple of changes to TAP8 (here) that clarify roles and keys as well as making a slight change to the timing of a rotate file check to ensure the file is always found.

[mnm678]

@hannesm @JustinCappos Any thoughts about the role vs key rotation mentioned above? I was planning to go ahead with role rotation unless there's a reason to do the key rotation instead.