Grease and software that can be updated #8
Description
The original spec states that:
"Roughtime is only available for products that can be updated"
Summarizing here the rationale for this statement:
- Deliberate injection of faults by server implementations will help to surface bugs in client implementations before they become BlackHat talks. Buggy clients require updating to "survive" in a Roughtime ecosystem of "semi-honest" servers.
- Roughtime servers need to be able to come-and-go. We don't want more hard-coded server addresses leading to NTP like debacles. Future versions of the protocol might enforce this by requiring clients to provide a value or per-server id to prove it has an up-to-date server list.
Q: Should injection of deliberate faults, A.K.A. "Grease", be mandatory?
This draft makes implementation of server response fault-injection ("Grease") optional (a "MAY"). I wonder, given the stated design intent, if this RFC is the opportunity to mandate that conforming server implementations "MUST" implement "Grease".
The original spec doesn't quite go so far to say this is required: "...we plan on having Roughtime servers return invalid, bogus answers to a small fraction of requests" (emphasis added). But clearly deliberate faulty responses are a centerpiece of the intent.
Q: Decide now that "client freshness" is out of scope for this RFC?
No current implementations have any feature similar to the original spec's idea the the protocol might "...add a per-server id in the future that clients would need to send in order to prove to the server that they have a current server list...".
This feature would depend on defining a canonical "known good" server list which also does not exist.