Long-term state and distributed participants

[Nikita Borisov]

I like how you call out the issues of consistency in the long-term state discussion. One thing that might be worth pointing out is that a protocol that may look like a simple two-party protocol can in fact turn into a distributed protocol when implemented. E.g., a cryptographer might think mTLS is a protocol between a client and server, but when actually implementing it, the client may actually want keys stored on multiple devices, and the server may be distributed across a bunch of servers for parallelism and locality.

This suggests two axes that are important to consider in terms of long-term state:

1. How often does the state change? A never-changing state (e.g., private keys in TPMs) is easiest to support; most long-term private keys will be in the rarely changing bucket since key rotation must be supported, but some protocol state must change all the time, such as anything to do with replay protection
2. What are the consistency requirements? Can the protocol tolerate some level of inconsistency? When things are inconsistent, do you have a recovery mechanism? An availability failure? A security failure?