Datastore: System clocks do step back

[ecpullen]

The system_time function in the data store is designed to prevent a clock from stepping back while reading targets; however, some systems do step back. Should there be a tolerance for the stepped back time?

[webern]

Or... should the system clock step back check exist at all?

[jpculp]

I think the step back check has a valid purpose, but it should allow for a short window of variance (1s? 3s?).

[webern]

has a valid purpose

Maybe, but it only protects against an attack vector where the system clock steps back during the metadata validation process. I don't think there's anything stopping an attacker from setting the system clock back before the whole process starts, which seems easier to do in the first place.

I don't have a total grasp over the attack vector and the mitigation that system_time affords. If we understand it then we should probably start by deeply documenting it. Right now all it says is:

tough/tough/src/lib.rs

Line 590 in d5c30ee

/// Ensures that system time has not stepped backward since it was last sampled

What's missing is why. What are we mitigating exactly.

1s? 3s?

This kind of illustrates the problem. What is a valid fudge factor for bad clocks? Who knows?

[webern]

Put differently, is there a critical point in the metadata validation algorithm in which stepping the clock back would be more beneficial to an attacker than having done that before the start of the algorithm?