grease

[teaishealthy]

Defined in https://datatracker.ietf.org/doc/html/draft-ietf-ntp-roughtime-15#section-7

The primary purpose of grease is to prevent protocol ossification, which could prohibit future protocol extensions and development [RFC9170]. In Roughtime, grease is also intended to ensure that clients validate signatures. To grease the Roughtime protocol, servers SHOULD send back a fraction of responses with any of the following: lack of mandatory tags, version numbers not in the request, undefined tags, or invalid signatures together with incorrect times. Clients MUST properly ignore undefined tags and reject invalid responses. Servers MUST NOT send back responses with incorrect times and valid signatures. Either signature MAY be invalid for this application.

Implementation considerations:

• grease should be fully supported in the cli by the client and server

client:

• the library client send_request shouldn't accept grease by default, this should be left up to the user or a higher level abstraction such as request_time
• in the cli we should try to resend the same request and see if that improves anything
• what to do about servers that grease during an ecosystem query? they might just ruin the entire query chain and we'd have to re-query all servers again. also, what if a server greases during the status check but would've actually been fine to select as a server.

roughly server:

• im thinking to put grease into a middleware layer of sorts, pick some fraction (??) of requests and parse them again, grease, and repack. this should be configurable though, i don't want roughly to seemingly end up failing interop tests because it started greasing requests, ideally via --no-grease, ROUGHLY_NO_GREASE

• dropping mandatory tags

• dropping version numbers (?)

• undefined tags

• wrong time with wrong signature: this should be pretty much a given considering the way we implement grease.