Explanation

Early Termination

The specification governs

This page explains the design of the Vultron Protocol. It is informative: the normative text is the Vultron Protocol Specification. Where this page and the specification differ, the specification governs.

Embargoes sometimes terminate prior to the agreed date and time. This is an unavoidable, if inconvenient, fact arising from three main causes:

Vulnerability discovery capability is widely distributed across the world, and not all Finders become cooperative Reporters.
Even among otherwise cooperative CVD Participants, leaks sometimes happen.
Adversaries are unconstrained by CVD in their vulnerability discovery, exploit code development, and use of exploit code in attacks.

Be Prepared for Embargo Termination

While many leaks are unintentional and due to miscommunication or errors in a Participant's CVD process, the effect is the same regardless of the cause. As a result,

Participants SHOULD be prepared with contingency plans in the event of early embargo termination.

Reasons to Terminate an Embargo Early

Some reasons to terminate an embargo before the agreed date include the following:

Formalism

\(q^{cs} \in \{ \cdot\cdot\cdot P \cdot\cdot, \cdot\cdot\cdot\cdot X \cdot \}\)

Embargoes SHALL terminate immediately when information about the vulnerability becomes public. Public information may include reports of the vulnerability or exploit code.

Formalism

\(q^{cs} \in \{ \cdot\cdot\cdot\cdot\cdot A \}\)

Embargoes SHOULD terminate early when there is evidence that the vulnerability is being actively exploited by adversaries.

Embargoes SHOULD terminate early when there is evidence that adversaries possess exploit code for the vulnerability.

Embargoes MAY terminate early when there is evidence that adversaries are aware of the technical details of the vulnerability.

The above is not a complete list of acceptable reasons to terminate an embargo early. Note that the distinction between the SHALL in the first item and the SHOULD in the second is derived from the reasoning given in the CS model , where we describe the CS model's transition function. Embargo termination is the set of transitions described in the EM formal model. A termination ends the embargo in force and cancels every proposal still open, in one step on the case's embargo register. No Participant's embargo consent is written when an embargo terminates. Each Participant's position follows from the register: with no embargo in force, nobody is bound by one, and every consent row for the ended and canceled embargoes stays as it stood (§7.3 Relationship to Embargo Consent in the Vultron Protocol Specification). Once a case's embargo has terminated, its register takes no further change, so the case cannot be put under a new embargo.

Recording Why an Embargo Ended

Every termination records what ended the embargo: it reached its end time (END_TIME_REACHED), or it ended early (EARLY). The termination message carries that reason, and every Participant records it. An early termination may also record why the embargo ended, as one of four kinds of cause:

Cause	Detail	Who may name it
`THREAT_SIGNAL`	The signals that ended it: public awareness (`P`), a public exploit (`X`) or observed attacks (`A`)	The Case Manager only
`FIX_READY`	The Vendors whose readiness made the quorum	The Case Owner or the Case Manager
`FIX_DEPLOYED`	None	The Case Owner or the Case Manager
`OTHER`	None; the termination message's human-readable summary gives the account	The Case Owner or the Case Manager

An embargo that reached its end time has no cause, and an early termination with no cause is valid. The termination message carries the cause beside the reason, and the Case Manager records both on the ended embargo's entry in the case's embargo register. When the Case Owner names FIX_READY, FIX_DEPLOYED or OTHER, the Case Manager records that cause as the Case Owner gave it, without checking it: ending early on a quorum of Vendors is the Case Owner's judgment. A Case Owner does not name a threat signal in a termination message, and the Case Manager refuses one that does. Instead, the Case Owner reports the threat as a case status update setting P, X or A, and the Case Manager then ends the embargo with the signals the case carries.

When the End Time Passes

An embargo does not end by itself when its end time passes. The Case Manager ends it with the reason END_TIME_REACHED, and the termination runs the same steps as any other: open proposals are canceled, the case leaves the embargo, and every Participant is told. The Case Manager checks the end time the next time it handles the case, whether for an incoming message or one of its own actions, so no scheduler is needed. It checks only after confirming that the sender of the message may send it, so a message from someone with no standing in the case never makes the Case Manager end the embargo. A request to end the embargo early that arrives after its end time is recorded as END_TIME_REACHED, because the embargo had already reached its end. An outside service, such as a Sentinel watching embargo timers, can also ask the Case Manager to end the embargo at its end time. The two requests share one path: whichever arrives second finds the embargo already ended, and nothing more is sent. A termination that claims the end time was reached before it was is refused.

Waiting for All Vendors to Reach Fix Ready May Be Impractical

Fix Ready Definition

\[q^{cs} \in VF\cdot\cdot\cdot\cdot\]

It is not necessary for all Vendor Participants to reach Fix Ready before publication or embargo termination. Especially in larger MPCVD cases, there comes a point where the net benefit of waiting for every Vendor to be ready is outweighed by the benefit of delivering a fix to the population that can deploy it. No solid formula for this exists, but factors to consider include

the market share of the Vendors in Fix Ready (\(q^{cs} \in VF \cdot \cdot \cdot \cdot\)) compared to those that are not (\(q^{cs} \in \cdot f \cdot \cdot \cdot \cdot\))
the software supply chain for fix delivery to Deployers
the potential impact to critical infrastructure, public safety/health, or national security

Embargoes MAY terminate early when a quorum of Vendor Participants is prepared to release fixes for the vulnerability (\(q^{cs} \in VF\cdot\cdot\cdot\cdot\)), even if some Vendors remain unprepared (\(q^{cs} \in \cdot f \cdot\cdot\cdot\cdot\)).

Participants SHOULD consider the software supply chain for the vulnerability in question when determining an appropriate quorum for release.

Doing It on the Wire

How to Revise or Terminate an Embargo — end an active embargo, early or at its agreed time.
How to Establish an Embargo — propose and activate an embargo on a case that has not yet had one end.

Reading path: You handle vulnerability reports and coordinate cases with other organizations

This page is part of See how a case moves.

Before this page:

Adding Participants to an Embargoed Case

After this page:

How to Adopt Vultron in Your CVD Program

Back to the start of this reading path