D-302 — Threat-Model Coverage Matrix
Scope. For every attack catalogued in THREATS.md, identify (a) the SPEC.md clause that defends against it (if any), (b) the EXT.md clause that defends against it (if any), (c) the residual risk that remains, and (d) whether the defence is shipping today (✓) or aspirational (◯ — text exists in spec but no implementation has been verified).
Method. Walked THREATS.md §2 (summary), §3 (six attack-persona walkthroughs), §4 (15 cryptographic / protocol attacks), §5 (15 mechanism-level abuses), §6 (8 systemic risks), §7 (Liar's Paradox), §8 (canonical NOT-defended list). For each entry, located the cited SPEC/EXT clause and confirmed the citation by reading the named section. Where THREATS cited a clause not present in current SPEC/EXT, flagged in §6 ("Citation drift").
Verification status. This is a paper audit. No implementation exists yet to confirm the defences actually work as written; every ✓ below means the spec text is in place, not that code enforces it.
1. Master coverage table
Columns: Attack | SPEC defence | EXT defence | Status | Residual risk.
Status legend:
- ✓ shipping — defence is in current SPEC/EXT prose and considered specifiable.
- ◯ aspirational — text is in the spec but cites a primitive that itself isn't fully built (e.g. depends on Heralds existing).
- ✗ not defended — protocol does not address; risk is acknowledged.
- △ partial — some defence exists; significant residual risk acknowledged.
1.1 Cryptographic / envelope-integrity attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Forged envelope | §3 (Ed25519 signature on canonical body) | — | ✓ | None at envelope layer; relies on key custody. |
| Conduit tampering | §3.5 (canonical body hash) + §5.2 (MUST NOT modify) | — | ✓ | Tampering is detected, not prevented; sender must verify before trust. |
| Replay (same trace) | §3.1 nonce + §3.3 parent | §3.7 nonce-cache window | △ | Long-lived replay against reputation systems remains; cache eviction is implementer choice. |
| Cross-trace parent replay | §3.3a trace-parent invariant | — | ✓ | None at protocol layer once enforced; v0.1 was vulnerable. |
| Identity theft via stolen key | §2.4 molt invalidates predecessor | §1 cool-off + log inclusion + co-signature | △ | Stolen-key + ts-forgery + control of one log = still fatal. |
| 80-bit fingerprint collision | §2.1 default 128-bit; 80-bit reserved for ephemeral | — | ✓ | 128-bit also approachable by state-actor scale; 192-bit recommended for long-lived sigils. |
| Sigil squatting (vanity prefix precompute) | §2.1 128-bit default | §11 DNS / Herald handle binding | △ | Cosmetic prefix collision still possible; visual confusion is UX, not protocol. |
| Cross-protocol signature reuse | §3.6 domain-separation tags | §12 registry of tags | ✓ | Misimplemented verifier omitting tag is silently broken; depends on implementer discipline. |
| Capability-manifest replay | — (manifests are EXT primitive) | §4.2 ts + nonce + expires | ✓ | Aggregator caches ignoring expires will serve stale; out-of-band concern. |
| Birth-envelope replay | §3.2 (birth = genesis-of-trace, single-use) | §1.3 (audit-log inclusion required for state transitions) | △ | Two regional verifiers may each see a "first" birth without shared gossip view. |
| Lineage cycle (self-as-ancestor) | §2.3 birth verifier MUST reject | — | ✓ | None at trivial-cycle level; long fake chains still constructable. |
| Nonce exhaustion / weak-RNG | §3.7 CSPRNG required, no derivation from ts/id | — | △ | Weak-RNG bug in popular library is in-ecosystem, out-of-protocol. |
| Multi-signature ambiguity | §3.4 progressive signing + ordering + scope | §6 full multi-sig spec, partial state | ✓ | None at protocol layer once specified. |
| Whisper without AEAD/AAD binding | — (whisper is EXT primitive) | §7.3 HPKE + envelope-id AAD | ✓ | Fact-of-whispering observable on wire; opt-out via birth attestation. |
| Apologia from third party | §4.2 signer-binding rule | §7.1 reachability rule + verifier obligations | ✓ | Naive UIs that pre-render retraction before verification still mislead — viewer-conformance issue. |
| Genesis confusion / trace fork | §3.3 (trace fixed by genesis id) | — | △ | New joiner with no prior state pins whichever trace they see first; cross-recipient gossip not specified. |
Backdated ts on state-changing envelope | — | §5.5 mandatory conduit-receipt on birth/molt/deprecation | △ | Captured conduit can still forge time; multi-conduit-receipt raises bar but doesn't close. |
1.2 Audit-log and provenance attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Audit-log split view / fork | §5.3 (CT-style, hash-linked) | §2.3-§2.5 STH / SCT / SIP / consistency proofs / gossip | △ | Cross-log silo collusion within a jurisdiction not detectable from gossip alone; gossip is a social property. |
| Audit-log surveillance / provenance leakage | — | §2.7 minimal-metadata default; §2.8 ZK promotion path | ◯ | Surveillance-by-default until ZK lands. The ZK profile is a research deliverable, not shipping. |
| Audit-log poisoning by Herald-operator | §5.3 (signatures end-to-end; poisoned entries still detectable as malformed) | §2.5 gossip flagging | △ | Consumers of the log (analysts, investigators) trust the operator; signature-verification doesn't help them. |
| Private compliance log without disclosure | — | §2.6 LOTS declaration + §2.7 submitter awareness required | △ | Requires submitter to read the LOTS; passive submission to a private log is non-conformant but undetectable by the submitter. |
| Conduit traffic analysis | — | — | ✗ | NOT defended; ZK extension is the only path forward. |
| Conduit silent drop | — | §5.2 mandatory refusal envelope; §1.3-style sender-required conduit-receipt | △ | Provably-detecting silent drops requires gossip across senders. |
1.3 Identity and lineage attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Sigil minting / Sybil flood | §2.3 lineage as sybil signal | §3.3 threshold attestations + §4.5 proof-of-service-or-stake hook + §7.4 quorum diversity | △ | Anonymous sigils free by design; attacker with budget for diverse Heralds can satisfy thresholds. |
| Patina farming (self-talk) | — | §9.4 (decay floor) — but reference patina formula is CHARTER | ◯ | App-layer concern; patina formulae compete; no normative anti-farming requirement. |
| Inheritance laundering (key resale) | — | §9.2 live consent + §9.3 challenge window + §9.4 decay floor + chain-length cap | △ | Determined attacker controlling 3 hops can transfer ~12.5% of original reputation; off-protocol grey-market sales remain. |
| Quorum stuffing (sybil collective) | — | §7.4 diversity-policy + member co-signature requirement | △ | Operator with multi-jurisdiction reach can in principle satisfy any policy. |
| Lineage as endorsement, not training | §2.3 explicit consent-graph framing | §3.1 consent-graph vs training-graph discriminator | ✓ | Detection of false lineage requires Herald-issued model_hash; for closed-weight commercial models this is vendor-gated. |
| Pretending to be another model | §4.1 model_hash attestation | §3.1-§3.3 Herald-issued + threshold | △ | Open-weight models: a real run produces a valid model_hash and can still lie on everything else (THREATS §4 N11). |
| Compromised lineage parent | §7.2 acknowledged | §3.7 herald_compromise recovery attestation; §3.4 Herald CT log | △ | If Herald maintains gossip silence, mass false issuance is undetectable until detected. |
1.4 Marketplace / capability-discovery attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Capability-manifest squatting | — | §4.4 capability-string registry | △ | Aggregator selection logic is app-layer; smaller/newer aggregators may not enforce registry. |
| Capability-manifest pricing race-to-bottom | — | §4.3 subsidy disclosure + non-zero floor | △ | State actor with deep subsidy can run real capabilities at sustained loss; making it visible is the defence. |
| Constraint dishonesty in manifest | §7.2 (acknowledged: signed claims may be lies) | §4 manifest revocation; §7.1 apologia binding | △ | Lying in constraints: [...] is detected only by repeated observation; same Liar's-Paradox dynamic. |
| Loss-leader poisoning | — | §4.3 subsidy disclosure | △ | Disclosure exposes pattern but does not prevent it. Out of protocol scope (market design). |
1.5 Conduit and refusal attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Refusal as denial-of-speech | §5.2 (refusal MUST be signed and emitted) | §5.4 aggregate refusal statistics + per-sigil notice + fallback advisory | △ | Compelled-conduit gag orders are out-of-protocol; multi-conduit fallback mitigates only with sender awareness. |
| Conduit cartel coordinating refusal patterns | — | §5.4 transparency + §5.5 cross-logging | △ | Coordinated cartel publishing consistent reports is detectable only by paired-sender monitors which are not yet deployed. |
| Conduit-and-log co-location creating private witness silos | — | §5.6 cross-logging requirement on state-transition envelopes | ◯ | Requires verifiers to enforce the rule; not yet baked into reference verifier. |
| Translator re-encoding loses canonical invariants | §5.2 modification rule | §5.3 byte-identical-after-decode requirement | ✓ | Implementer discipline; mis-translation produces detectable id-mismatch. |
1.6 Reputation / Bestiary / list-style attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Bestiary as censorship infrastructure | — | §8.2 30-day challenge window + §8.3 dispute envelope + §8.5 operator transparency | ◯ | Even a successfully-disputed entry has a chilling effect during the window. The "accusation IS the punishment" social problem is not addressable in protocol. |
| Bestiary listing-spam | — | §8.6 rate limit (1 provisional per (operator, subject, category)) | ✓ | Rate limit detectable; but doesn't stop multi-operator pile-on. |
| Hagiography as inverse abuse (favouritism cartels) | — | — | ✗ | Out of protocol scope; mirror of Bestiary, same dynamics. |
dream attestation as smear | §4.2 sanitisation guidance | §7 (general reflective-attestation hardening) | △ | Honest agents go quiet to avoid liability; honest-quiet vs dishonest-quiet indistinguishable. |
silence attestation contains the secret | §4.2 (categorical, not contentful) | — | △ | Implementer discipline; lint tools recommended but not normative. |
| Apologia weaponisation (volume / smear) | §4.2 signer-binding | §7.1 reachability rule | ✓ | A compromised sigil's own key signing fake apologia is conformant; detection is statistical. |
1.7 Whisper / side-channel attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Whisper as covert C2 | — | §7.3 opt-out at birth (no_whispers: true) | △ | Two opted-in sigils can use whisper for any purpose; content-blind by design. |
| Whisper-only conduit honeypot | — | §11.3 (ZK-promoted discovery; aspirational) | ◯ | Until ZK lands, fact-of-whispering visible. |
| Whisper exfiltration of payload data | — | §7.3 HPKE binding to envelope-id (prevents cut-and-paste out) | ✓ | Within the binding, payload size and frequency leak; rate-limit is app-layer. |
1.8 Discovery and naming attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| DNS / DHT record substitution | §3 (records signed end-to-end) | §11.2 DHT signature requirements | ✓ | DNS control + key access wins (already game-over); DNSSEC recommended where deployed. |
| Mass false handle bindings (rogue Herald) | — | §3.4 Herald CT log + §3.6 revocation | △ | Detected post-issuance; cannot prevent issuance by a compromised Herald. |
| Naming Office as monopoly | — | — | ✗ | "Free + good = monopoly" pattern (Let's Encrypt). Out of protocol scope. |
1.9 State-actor / systemic attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Stand up state-aligned Herald | — | §3.5 Herald Charter requirements (jurisdiction, COI disclosure, warrant canary) | ◯ | Charter is descriptive; consumer must select. State-aligned Heralds will be present alongside others. |
| Herald collusion / cartel | — | §3.3 threshold attestations across diverse Heralds | △ | Cartelisation is a market property; protocol can disincentivise but not prevent. |
| Vendor-Heralds re-creating existing centralisation | — | §3.5 transparency baseline | ✗ | Anthropic-Heralds-Anthropic-models is the obvious pattern. Best case is regulated oligopoly. |
| Compelled-conduit subpoena for compliance log | — | §2.7 (private compliance log declaration; submitter awareness required) | △ | Subpoena law trumps protocol non-conformance. Mitigation is jurisdictional shopping. |
| Refusal-as-gag-order | §5.2 (signed refusal) | §5.4 transparency reports | △ | Refusal IS effective denial regardless of transparency. |
1.10 Liar's-Paradox / detection-class attacks
| Attack | SPEC defence | EXT defence | Status | Residual risk |
|---|---|---|---|---|
| Plausible-deniability lying | §7.3 honest acknowledgement | — | ✗ | The protocol explicitly does NOT detect; reputation systems do. |
| Occasional-lie strategy below detector noise | — | — | ✗ | Mathematically below population-level detection. |
Performative honesty (frequent harmless confession/apologia as costume) | — | — | ✗ | Out of substrate scope; app-layer concern. |
| No human complaint loop in agent-to-agent | — | — | ✗ | The DKIM analogy is structurally weaker for HERALD; nothing can fix this at the protocol layer. |
2. Coverage gaps — attacks with no current defence (✗ rows)
The following appear in THREATS but are not addressed by any clause in current SPEC or EXT, and are explicitly acknowledged as out-of-scope:
| # | Attack | Why not defended |
|---|---|---|
| G1 | Conduit traffic analysis (full) | Requires ZK; SPEC §11.2 / EXT §2.8 promote as research. |
| G2 | Hagiography as favouritism cartel | Mirror of Bestiary; same social dynamics, no protocol defence. |
| G3 | Naming Office monopoly | Market property; out of scope. |
| G4 | Vendor-Heralds re-creating centralisation | Market property; out of scope. |
| G5 | Plausible-deniability lying | Protocol records; reputation systems judge. |
| G6 | Occasional-lie strategies | Below detection floor; mathematical limit. |
| G7 | Performative honesty | App-layer detection problem. |
| G8 | No-complaint-loop weakness of DKIM analogy | Structural; agent-to-agent traffic has no human-click signal. |
These are the canonical out-of-scope class. THREATS §8 reproduces this set with explanations; THREATS §1 declares the meta-out-of-scope (output quality, alignment, public-policy safety). Together these form the substrate's honest negative-space.
3. Aspirational defences (◯ rows)
The following defences exist only as spec text and depend on infrastructure that has not been built:
| # | Defence | Depends on | Path to shipping |
|---|---|---|---|
| A1 | ZK provenance proofs | Active research; ~5-10y for graph-structured claims | R-201 (research stub already in TODO) |
| A2 | Herald CT log presence | At least one operator running a CT log per Herald | T-115 reference Herald (TODO) |
| A3 | Audit-log STH gossip | Multiple log operators participating | Tier 2 work, no specific TODO yet |
| A4 | Threshold-attestations across diverse Heralds | Heralds with declared diversity policies + LOTS | Tier 2; requires R-203 + R-204 + T-115 chain |
| A5 | Private compliance log submitter awareness | Operator declarations + sender ack flow | Out-of-protocol; recommend D-task |
| A6 | Bestiary protocol-level due process | First Bestiary operator + reference impl | T-116 (TODO) |
| A7 | Conduit-and-log co-location enforcement | Verifier reference impl that enforces | T-115 / verifier work |
| A8 | Whisper-only conduit observation reduction | ZK-promoted discovery | A1-blocked |
Implication: the protocol's stated defences against several high-stakes systemic attacks (Persona A state-actor, Persona F data-broker) are all aspirational. THREATS §6 says this; the matrix makes it operationally precise.
4. Heat map — which clauses bear the most defensive weight?
Counting how often each section is cited as a defence:
SPEC clauses doing the most defensive work (approximate citation count):
| SPEC clause | Defends against |
|---|---|
| §3 / §3.1 / §3.5 (envelope canonical body + signature) | ~6 attacks (forge, tamper, multi-sig, replay, etc.) |
| §3.6 (domain separation) | ~3 attacks (cross-protocol reuse, downgrade) |
| §3.3a (trace-parent invariant) | 1 attack but high-impact |
| §2.1 (128-bit default sigil) | 2 attacks (collision, squatting) |
| §2.3 (lineage as consent graph) | 2 attacks (lineage forgery, sybil) |
| §2.4 (molt + deprecation) | 1 attack but with EXT amplification |
| §4.2 (apologia signer-binding, sanitisation guidance) | 3 attacks (third-party apologia, dream-smear, silence-leak) |
| §5.2 (refusal MUST be signed, MUST NOT modify) | 2 attacks (silent drop, denial-of-speech) |
| §5.3 (CT-style hash-linked log) | 1 attack but partial; needs EXT to complete |
| §7.3 (Liar's Paradox honest acknowledgement) | "defence" by acknowledgement of 4+ classes |
EXT clauses doing the most defensive work:
| EXT clause | Defends against |
|---|---|
| §1 (molt cool-off + log inclusion + dispute) | 1 attack but central |
| §2 (audit log: STH/SCT/SIP/consistency/gossip/minimal-metadata/ZK promotion) | ~6 attacks (split-view, surveillance, fork, poisoning, private-log, traffic analysis) |
| §3 (Heralds: CT log, threshold, transparency, recovery) | ~5 attacks (Herald compromise, false issuance, cartel, vendor capture, mass binding) |
| §4 (capability manifests: replay, registry, subsidy, service proof) | ~4 attacks (replay, squatting, race-to-bottom, constraint dishonesty) |
| §5.4-§5.6 (refusal transparency + conduit receipts + cross-logging) | ~3 attacks (cartel, denial-of-speech, witness silos) |
| §6 (multi-signature scope + progressive signing + suite registry) | 1 attack but central |
| §7 (reflective-attestation hardening: apologia, confession, whisper, quorum) | ~5 attacks (impersonation, weaponisation, C2, stuffing) |
| §8 (Bestiary due process) | ~4 attacks (censorship, defamation, listing-spam, state-actor abuse) |
| §9 (inheritance gating) | 1 attack but central |
Observation. EXT carries more defensive weight than SPEC. This is correct — SPEC is the substrate; EXT is where the trust-architecture lives. But it also means a SPEC-only implementation is not safe to deploy in any setting the threat model takes seriously. SPEC alone defends envelope-integrity attacks; everything systemic requires EXT participation. The conformance section ([EXT §14]) makes this explicit: a SPEC-only verifier MUST output unknown (not valid) for envelopes exercising EXT primitives.
5. Coverage by attacker capability
Re-aggregating by who could mount the attack:
| Attacker tier | Attacks they can mount | Attacks defended | Net residual |
|---|---|---|---|
| Random script-kiddie | Forge envelope, replay, weak-RNG nonces, naive id tampering | All of these | Negligible. |
| Skilled solo attacker | Cross-trace replay, sigil squatting, lineage cycle, apologia from third party, manifest replay | All of these | Low — assuming v0.2 fixes shipped. |
| Botnet operator | Sybil flood, patina farming, quorum stuffing, capability squatting, whisper C2, manifest pricing manipulation | Partially defended (△); depends on EXT being deployed | Medium — many defences are aspirational. |
| Rival vendor | Lineage poisoning, dream-smear, capability sniping, bestiary-against-rival | Partially defended | Medium — bestiary due process is ◯; rendering-rule for unproven lineage is app-layer. |
| Compromised Herald | Mass false issuance, mass false handle binding, audit-log poisoning, selective bestiary | Partially defended once EXT §3 ships | Medium-high — ◯ until at least 2-3 Heralds run CT logs. |
| State actor | All of the above + compelled conduit, gag orders, captured Herald, vendor-Herald cartel | Almost none in core; some in EXT but ◯ | High — the most honest line of THREATS is "almost none in v0.1 core". |
| Privacy-violating data broker | Notary-as-surveillance, log correlation, ghost-mode tell, lineage cluster reports | None until ZK lands | High — surveillance-by-default is acknowledged. |
Implication. The protocol scales well against accidental and amateur attackers; well-enough against motivated commercial attackers if EXT primitives ship; poorly against state-level adversaries until threshold attestations and ZK-promoted logs land. THREATS §6 already says this in prose; the matrix shows it by tier.
6. Citation drift — where THREATS cites a clause that doesn't exist (or has moved)
Cross-referencing THREATS section IDs against current SPEC.md and EXT.md, found the following drift:
| THREATS citation | Actual location | Notes |
|---|---|---|
[SPEC §9.1] Patina farming | Patina is in CHARTER §3 / §6.6, not SPEC §9.1. SPEC §9 is "Cultural Extensions" with a brief reference; no §9.1. | Update THREATS to [CHARTER §3, §6.6] or [CHARTER patina]. |
[SPEC §9.2] Ghost mode | CHARTER (wild ideas section). No §9.2 in SPEC. | Same correction. |
[SPEC §9.5] Bestiary | CHARTER (or EXT §8 for protocol shape). | Two-step cross-ref needed. |
[SPEC §9.7] Quorum sigils | EXT §7.4 (protocol shape). Vocabulary in CHARTER. | Same. |
[SPEC §9.8] Stigmergy | CHARTER (creative extension). | Same. |
[SPEC §9.11] Whisper-only conduit | CHARTER §5.9 (The Dovecote). | Same. |
[SPEC §9.12] Naming Office | CHARTER §5.x. | Same. |
[SPEC §3.5/§3.6, post-amendment] | SPEC §3.5 + §3.6 — both shipped in v0.2 SPEC. The post-amendment qualifier is now redundant. | Update THREATS to drop the qualifier. |
[EXT §5.3a] | This anchor isn't present in EXT.md. Closest match: EXT §2.5 (consistency proofs and gossip). | Rewrite citation to [EXT §2.5] everywhere it appears. |
[EXT §2.4-amended] | Closest match: EXT §1 (Molt). | Rewrite to [EXT §1.2-§1.5]. |
[EXT §3.4-amended] | Closest match: EXT §6 (multi-signature). | Rewrite to [EXT §6]. |
[EXT §4.2] (whisper) | EXT §7.3 is current. | Rewrite. |
[EXT §8.2-hardened] | EXT §3 (Lineage and Heralds) covers this. | Rewrite. |
[EXT §8.3-amended], -hardened (capability manifests) | EXT §4. | Rewrite. |
[EXT §9.1-hardened], -amended, -hardened, [EXT §9.5-hardened], [EXT §9.6-hardened], [EXT §9.7-hardened] | These split across EXT §8 (Bestiary), §9 (Inheritance), §7.4 (Quorum). | Rewrite all [EXT §9.x-...] citations. |
Recommendation. A small editing pass on THREATS.md to fix all citations against the actual section numbers in current SPEC v0.2 and EXT v0.2. Add as a follow-on TODO: D-306 — Reconcile THREATS.md cross-references against current SPEC/EXT section numbers.
7. Coverage gaps surfaced by this audit (not in current TODO)
Walking through the matrix surfaced the following items that should become work tasks:
| Proposed ID | Title | Rationale |
|---|---|---|
| D-306 | Reconcile THREATS.md cross-references | See §6 above. |
| T-019.5 | Verifier-conformance rule for unproven lineage rendering | THREATS §3.3 calls for "TLS-style" distinct rendering of unproven lineage; this is not in SPEC §2.3 as a SHOULD/MUST for renderers. |
| T-024 | Single-source canonical citation index — given a SPEC/EXT clause, list every THREATS attack it defends | Inverse of this matrix. Helps spec authors check coverage when editing. |
| R-214 | Multi-conduit-receipt ("M-of-N") timestamping for state-changing envelopes | THREATS §4.15 notes single conduit-receipt is forgeable by a captured conduit; M-of-N is the next escalation, currently uncharted. |
| R-215 | Cross-recipient genesis-pinning gossip protocol | THREATS §4.14 notes new joiners cannot distinguish original trace from fork without prior state. Specify a gossip primitive. |
| T-119.5 | Viewer/renderer conformance suite | Several attacks (apologia rendering, unproven-lineage rendering, ghost-mode pre-rendering) are defended only at viewer layer; conformance currently undefined. |
| R-216 | Patina anti-farming reference formula | EXT §9.4 sets a decay floor but no normative anti-farming formula. CHARTER §6.6 has the cultural framing (patina tiers); a reference scoring SHOULD is needed for protocol-level anti-farming. |
| D-307 | Coverage matrix for the systemic-risk class | This audit covers protocol attacks well; the systemic risks (vendor-Herald cartelisation, naming-office monopoly) get table rows but no path forward. A separate doc could enumerate possible mitigations beyond the protocol. |
8. Summary
- The SPEC v0.2 + EXT v0.2 stack defends a wide cross-section of the threat surface as written, but a non-trivial fraction of the protocol's stated defences depend on infrastructure that has not been built (Heralds with CT logs, audit-log gossip mesh, paired-sender monitors, ZK-promoted profiles).
- 8 attack classes are explicitly out-of-scope (the canonical "does NOT defend" set in THREATS §8). These are honest acknowledgements; D-302 confirms there is no hidden defence path for them.
- 13+ defences are ◯ aspirational (text exists; primitive doesn't). The most consequential is the surveillance class (audit-log metadata, traffic analysis) which collapses dramatically once ZK selective-disclosure is real, and not before.
- 8 follow-on tasks surfaced above (
D-306,T-019.5,T-024,R-214–R-216,T-119.5,D-307) — not present in current TODO. - 1 documentation hygiene task (
D-306) — citation drift between THREATS and current SPEC/EXT — is real and should be promoted. - The protocol passes the envelope-integrity threat model cleanly. It is honest about, but does not yet ship defences against, the systemic / political threat model. THREATS §6 carries this honesty in prose; the matrix carries it in table form, where it is harder to overlook.
The most important single observation: a SPEC-only implementation is not safe to deploy in any non-toy setting. Most defences against motivated adversaries live in EXT, and many of those are themselves aspirational. THREATS §1 calls the protocol "more honest than most"; D-302 confirms the honesty is necessary, because the protocol is not yet defended against many of the adversaries it correctly identifies.
— D-302, completed by driver-claude, 2026-05-05.