States
This page is normative
This page is considered a core part of the Vultron Protocol. This is a normative section of the documentation.
Each Participant in an MPCVD case has a corresponding RM state, an EM state, and an overall CS state. Therefore, we can represent a Participant's state as a triple comprising the state of each of these models.
Participant State
A Participant's state is a triple comprising the state of each of the RM, EM, and CS models.
Good Participant situation awareness makes for good CVD decision making.
Participants SHOULD track the state of other Participants in a case to inform their own decision making as it pertains to the case.
Elsewhere, we provide an example Case Object model to facilitate such tracking. However, the protocol we are developing is expected to function even when incomplete information is available to any given Participant.
Adequate operation of the protocol MUST NOT depend on perfect information across all Participants.
A generic state model for a CVD Participant can be composed from the Cartesian product of \(\mathcal{Q}^{rm}\), \(\mathcal{Q}^{em}\), and \(\mathcal{Q}^{cs}\) as shown below.
Participant State Space
A Participant's state is a triple comprising the state of each of the RM, EM, and CS models. The set of all possible Participant states is the Cartesian product of the RM, EM, and CS state sets.
Note that the above definition splits the case state (\(\mathcal{Q}^{cs}\)) into chunks corresponding to the Vendor fix path (\(vfd \xrightarrow{\mathbf{V}} Vfd \xrightarrow{\mathbf{F}} VFd \xrightarrow{\mathbf{D}} VFD\)) and the public-exploit-attack (\(pxa \xrightarrow{\dots} PXA\)) sub-models from the Case State Model. This is done for two reasons. First, it gives us a more compact notation to represent the 32 states of the CS model. Second, as described in Model Interactions, it highlights the fact that the Vendor fix path represents the state of an individual Participant, whereas the public-exploit-attack sub-model represents facts about the world at large. Because not all Participants are Vendors or Deployers, Participants might not have a corresponding state on the \(vfd \xrightarrow{} VFD\) axis. Therefore, we add a null element \(\varnothing\) to the set of states representing the Vendor fix path.
Thus, one might conclude that a total of 1,400 states is possible for each Participant.
Participant State Space Size
However, this dramatically overstates the possibilities for individual CVD Participant Roles because many of these states will be unreachable to individual Participants. In the remainder of this section, we detail these differences.
Unreachable States
For any Participant, the RM \(Closed\) state implies that the EM and CVD Case states do not matter. Similarly, for any Participant, the RM \(Start\) state represents a case that the Participant doesn't even know about yet. Therefore, the \(Start\) state also implies that the EM and CVD Case states do not matter. We use \(*\) to represent the "don't care" value.
Unreachable EM and CS States when RM is in Closed or Start
A public exploit implies the vulnerability is public as well. In other words, \(q^{cs} \in \cdot\cdot\cdot pX \cdot\) is an ephemeral state that resolves quickly to \(q^{cs} \in \cdot\cdot\cdot PX \cdot\). (As a reminder, dots (\(\cdot\)) in CVD case state notation indicate single-character wildcards.)
Unreachable CS States when CS is in Public or Exploit
Furthermore, when a vulnerability becomes public, the EM state no longer matters.
Unreachable EM States when CS is in Public
Taken together, we can modify our state model to reflect these limitations. The result is shown below.
Participant States With Unreachable States Removed
This means that each Participant must be in one of 352 possible states.
Participant State Space Size With Unreachable States Removed
Vendors (Fix Suppliers)
Vendors are the sole providers of fixes. Therefore, they are the only Participants in a CVD case for which the \(Vfd \xrightarrow{\mathbf{F}} VFd \xrightarrow{\mathbf{D}} VFD\) path is possible. Furthermore, since they are Vendors by definition, they do not have access to the \(vfd\) state or the \(\varnothing\) state that was just added. As a Vendor has a report in \(Received\), it is, by definition, at least in the \(Vfd\) case state.
Vendors create fixes only when they are in the \(Accepted\) RM state. Because the \(Received\), \(Invalid\), and \(Valid\) states come strictly before the \(Accepted\) state in the RM DFA, there is no way for the Vendor to be in either \(VFd\) or \(VFD\) while in any of those states.
Vendor CS States When RM is in Received, Invalid, or Valid
Vendors with the ability to deploy fixes themselves have access to three states in the fix path: \(\{Vfd,~VFd,~VFD\}\). However, this is not always the case. Vendor Participants without a deployment capability can only create fixes, limiting them to the middle two states in the fix path: \(\{Vfd,~VFd\}\). Additional discussion of the distinction between Vendors with and without a deployment capability can be found in A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure.
We apply these caveats to the generic model above to arrive at a Vendor state shown below.
Vendor Participant State Space
The \(\dagger\) on \(VFD\) in the above indicates that the \(VFD\) state is accessible only to Vendors with a deployment capability. As tallied below, there are 128 possible states for a Vendor with deployment capability and 100 for those without.
Vendor State Space Size
With deployment capability:
Without deployment capability:
Non-Vendor Deployers
We just explained that not all Vendors are Deployers. Likewise, not all Deployers are Vendors. Most CVD cases leave Non-Vendor Deployers entirely out of the CVD process, so their appearance is expected to be rare in actual cases. However, there are scenarios when an MPCVD case may include Non-Vendor Deployers, such as when a vulnerability in some critical infrastructure component is being handled or when the Vultron Protocol is used in the context of a Vulnerability Disclosure Program (VDP). These Non-Vendor Deployers participate only in the \(d \xrightarrow{\mathbf{D}} D\) transition on the fix path. Similar to the Vendor scenario above, it is expected that Deployers actually deploy fixes only when they are in the RM \(Accepted\) state (implying their intent to deploy). Therefore, their set of possible states is even more restricted than Vendors, as shown below.
Non-Vendor Deployer Participant State Space
Thus, Non-Vendor Deployers can be expected to be in 1 of 100 possible states, as we show next.
Non-Vendor Deployer State Space Size
Non-Vendor, Non-Deployer Participants
Finally, CVD cases often involve Participants who are neither Vendors nor Deployers. Specifically, Finder/Reporters fall into this category, as do Coordinators. Other roles, as outlined in the CERT Guide to Coordinated Vulnerability Disclosure, could be included here as well. Because they do not participate directly in the Vendor fix path, these Non-Vendor, Non-Deployer CVD Participants fall into the \(\varnothing\) case substate we added above. Their state model is shown below.
Non-Vendor, Non-Deployer Participant State Space
Non-Vendor Non-Deployer CVD Participants (Finder/Reporters, Coordinators, etc.) will be in 1 of 72 states, as calculated below.
Non-Vendor, Non-Deployer Participant State Space Size
Finder-Reporters
As we discussed in RM Interactions, the early Finder states are largely hidden from view from other CVD Participants unless they choose to engage in the CVD process in the first place. Therefore, for a CVD protocol, we only need to care about Finder states once they have reached RM \(Accepted\). Coincidentally, this is also a convenient way to mark the transition from Finder to Reporter.
Finder-Reporter State Space
Thus, for all practical purposes, we can ignore the hidden states in the above and conclude that Finders who go on to become Reporters have only 29 possible states during a CVD case.
Finder-Reporter State Space Size
A Lower Bounds on MPCVD State Space
Generic MPCVD State Space Size Formula
Now we can touch on the lower bounds of the state space of an MPCVD case. Generically, we would expect the state space for \(N\) Participants to take the form given at right.
The upper bound on the MPCVD state space is simply \(352^N \approx 10^{2.55N}\). However, because of the Role-specific limits just described, we already know that this overcounts the possible states significantly. We can do better still. If we ignore transient states while Participants converge on a consistent view of the global state of a case, we can drastically reduce the state space for an MPCVD case. Why? There are two reasons:
-
Because they represent facts about the outside world, the eight \(\cdot\cdot\cdot pxa \rightarrow \cdot\cdot\cdot PXA\) CS substates are global to the case, not to individual Participants. This means all Participants should rapidly converge to the same substate.
-
Similarly, the five EM states are also global to the case and should converge rapidly.
Given these two observations, we can pull those Participant-agnostic terms out of the state calculations for individual Participants,
MPCVD State Space With Participant-Agnostic Terms Factored Separately
where
which leaves
Participant-Specific State Spaces
So our state space looks like
MPCVD State Space Size Formula
With these values in mind, we see that
-
A two-party (Finder-Vendor) case might have a lower bound state space of \(40 \times 3 \times 16 = 1,920\) states.
-
A case like Meltdown/Spectre (with six Vendors and no Coordinators) might have \(40 \times 3 \times 16^{6} \approx 10^{9}\) states.
-
A large, but not atypical, 200-Vendor case handled by the CERT/CC might have \(40 \times 3 \times 16^{200} \times 7 \approx 10^{244}\) possible configurations.
-
In the case of the log4j vulnerability CVE-2021-44228 in December 2021, the CERT/CC notified around 1,600 Vendors after the vulnerability had been made public. Had this been an embargoed disclosure, the case would have a total state space around \(10^{2000}\).
That said, while these are dramatic numbers, the reader is reminded that the whole point of the Vultron Protocol is to coordinate the process so that it is not just hundreds or thousands of Participants behaving randomly.
Starting States
Each Participant begins a case in the state where the report management process is in the start state, there is no embargo in place, and the case has not made any progress.
Participant Start State Formally Defined
Following the discussion above, the starting states for Vendors, Deployers, and other Participants are shown below.
Participant Start States
Participant Role | Start State (\(o_i\)) |
---|---|
Vendor | \((S,N,vfdpxa)\) |
Deployer | \((S,N,dpxa)\) |
Other | \((S,N,pxa)\) |
Finder/Reporter | \((A,N,pxa)\) |
For a case to really begin, the Finder must at least reach the \(A\) state. Therefore, at the point when a second party finds out about the vulnerability from a Finder, the Finder/Reporter is presumed to be already at \(q_{Finder}=(A, N, pxa)\).
We will show in Transitions how this plays out. But first, we need to define the message types that can be exchanged between Participants.