Add description of version number scalability #72
Conversation
pep-0458.txt
Outdated
| *snapshot*, *targets*, *bins*, and *bin-n* roles may eventually loop back to 0 as long | ||
| as the previous 0-version metadata has expired before this occurs. To | ||
| prevent confusion, we suggest retiring the oldest metadata for each non-root | ||
| metadata type when 0.5*MAX_INT versions are in use. Root metadata can |
There was a problem hiding this comment.
Will the reader know what "0-version metadata" means? To me the term is confusing. And do you mean "expired" or "retired"? In the "Cleaning up old metadata" section we explain how metadata may be retired if it has become obsolete, which very likely happens before it has expired.
On the other hand, we must not retire metadata which has not yet become obsolete, even if its version number exceeds the 0.5*MAX_INT threshold. But that's very unlikely to happen. If we clean up metadata once per hour, it would need 0.5*MAX_INT metadata bumps within an hour to override.
But the stay on the safe side, maybe we can leave the details to the implementer and just say something along the lines...
To avoid integer overflows, the version numbers for *snapshot*, *targets*,
*bins*, and *bin-n* roles may be reset at regular intervals, under the
condition that no version number is used by two or more metadata files for a
role at the same time (cf. `Cleaning up old metadata`_ ). We suggest to retire
old metadata before `0.5*MAX_INT` versions are in use.
pep-0458.txt
Outdated
| prevent confusion, we suggest retiring the oldest metadata for each non-root | ||
| metadata type when 0.5*MAX_INT versions are in use. Root metadata can | ||
| not be retired, so the root metadata expiration should be set such that a | ||
| version number overflow is unlikely (ex. once a year). |
There was a problem hiding this comment.
I'd phrase this the other way around, that is root metadata bumps so rarely (once a year due to expiration, and after hopefully rare incidents like a compromise) that integer overflow is not an issue for root metadata. But you can also leave it as it is.
|
I just double-checked with the spec and it does point out in several places that clients MUST NOT replace a metadata file with a version number less than the one currently trusted. See root metadata VERSION definition and rollback attack detection for timestamp, snapshot and targets here and here. So if we do reset, we go against the spec, which might not be a problem per se. But we still need to find a safe way to allow a client to update from MAX_VERSION_NUMBER to 1. |
pep-0458.txt
Outdated
| snapshot. | ||
|
|
||
| In normal usage, version number overflow is unlikely to occur as an 8-byte | ||
| integer can be incremented once per millisecond and last almost 300 million |
There was a problem hiding this comment.
Minor nit: I'd not take it for granted that an 8-byte integer is chosen. Maybe we can phrase this more like a recommendation. Something like:
"... unlikely to occur. An 8-byte unsigned integer, for instance, can be
incremented once per millisecond for almost 300 million years."
What do you think?
There was a problem hiding this comment.
I agree, this was intended mostly as an example. I'll make that more clear.
pep-0458.txt
Outdated
| In normal usage, version number overflow is unlikely to occur as an 8-byte | ||
| integer can be incremented once per millisecond and last almost 300 million | ||
| years. If an attacker increases the version number arbitrarily | ||
| (e.g. to MAX_INT), the repository can recover by revoking the snapshot role |
There was a problem hiding this comment.
I wonder if it is clear to the reader what MAX_INT is. Also, not only snapshot role may need to be revoked, timestamp and top-level targets may too. Maybe we can say:
"If an attacker increases the version number arbitrarily, the repository can recover by revoking the compromised keys and reset the version number as described in the TUF specification__."
Co-Authored-By: lukpueh <luk.puehringer@gmail.com>
… number reset to make it more generic
lukpueh
left a comment
lukpueh
left a comment
There was a problem hiding this comment.
Thanks for the updates, @mnm678! This looks good to me. Let's merge so that the larger community may review in python#1203.
2 participants
Addresses #69
Describe the plan for integer overflow in version numbers.