max root rotations is way too small

[jku]

Our default configuration is max_root_rotations=32.

This is really quite small: a real world repository can reach this number if they are doing a bit of experimentation and then the default client can no longer update with a single refresh call (and the issue is hard to debug as refresh() may actually succeed but client does not yet have the most current root).

To start the discussion: 500 rotations would allow a weekly root signing (not something I'd recommend but not completely ludicrous) for almost 10 years without clients shipping with a newer root... That would be 0.25 GB of root metadata at most per client refresh (this is assuming a malicious repository that stuffs every version to max size). That sounds like something that should not be a critical issue to most computers today. Systems running on smaller embedded devices can modify the config of course.

Does 500 sound like too much as default?

CC @lukpueh @kommendorkapten

[lukpueh]

Hard to tell. Do I understand correctly, the attacker has root key access, but "only" tries to crash the client? Is that realistic? Also, it looks like setting "max root rotation" is not covered by the specification. I guess 500 is fine.

[kommendorkapten]

500 is ok, I did create a PR against go-tuf with 256, I can change that to 500 too, I don't have any strong opinions on the exact value as long as it's "large enough".

[jku]

Do I understand correctly, the attacker has root key access, but "only" tries to crash the client? Is that realistic?

Yeah that's the thing... needs a bit of imagination. For an embedded device bricking it by filling the disk might be a thing (would have to assume TUF is used for something that isn't interesting to attacker).

500 is ok, I did create a PR against go-tuf with 256

256 sounds reasonable too, we can go with that.

[JustinCappos]

Agree that this is very device specific. My general sense is that if an attacker controls your root keys and filling the disk is the worst they can do, you should feel fortunate... I'm in favor of this being higher rather than lower so that people don't accidentally bump up against the limit (which would be horrible)... I'd also like to check that this is per-repo? So, if I use 3 repos, each has a limit of this value, right?

…

On Mon, Jul 15, 2024 at 7:45 AM Jussi Kukkonen ***@***.***> wrote: Do I understand correctly, the attacker has root key access, but "only" tries to crash the client? Is that realistic? Yeah that's the thing... needs a bit of imagination. For an embedded device bricking it by filling the disk might be a thing (would have to assume TUF is used for something that isn't interesting to attacker). 500 is ok, I did create a PR against go-tuf with 256 256 sounds reasonable too, we can go with that. — Reply to this email directly, view it on GitHub <#2672 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD5AXBKZQJAGIHTZOFLZMOY4BAVCNFSM6AAAAABK4DJAOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRYGMYDKOJRGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kommendorkapten]

I'm in favor of this being higher rather than lower so that people don't accidentally bump up against the limit (which would be horrible)

Agree, this is the exact scenario we just ran into (in one of our staging TUF repos) when verifying the integrity from 1.root.json.

I'd also like to check that this is per-repo?

Yes, that's how it would work, as each repo would use it's own updater which is where the configuration option exists.

[JustinCappos]

So, as a thought experiment, what if we do not have a limit? This would stop one repo from flooding clients with extraneous root files and preventing an update to other clients. Is there another harmful situation? In general, if the root keys are compromised for a repo, some on-client-device action is likely needed.

…

On Mon, Jul 15, 2024 at 9:08 AM Fredrik Skogman ***@***.***> wrote: I'm in favor of this being higher rather than lower so that people don't accidentally bump up against the limit (which would be horrible) Agree, this is the exact scenario we just ran into (in one of our staging TUF repos) when verifying the integrity from 1.root.json. I'd also like to check that this is per-repo? Yes, that's how it would work, as each repo would use it's own updater which is where the configuration option exists. — Reply to this email directly, view it on GitHub <#2672 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD67QOTSF6QPANCZJC3ZMPCUFAVCNFSM6AAAAABK4DJAOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRYGQ3DMMJXGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[kommendorkapten]

Not having a limit is not optimal I think. Having a limit would at least get the client to halt, which I think is a valuable signal (theoretically the client will halt at some point in time, but with a limit it's easier to control and manage). Even if the client wont be able to continue normal operation, fail fast is preferable IMHO.