Chapter 45 — Independent design review

Chapter 45 — Independent design review

Lesson map

Lesson 45 published. Map, example, EX133.

flowchart TD
  N0["Learning outcomes"]
  N1["45.1 Preparing for review"]
  N2["45.2 Review findings"]
  N3["45.3 Responding"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX133"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["45.1 Preparing for review"]
  N2["45.2 Review findings"]
  N3["45.3 Responding"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX133"]

[Learning outcomes]
    |
    v
[45.1 Preparing for review]
    |
    v
[45.2 Review findings]
    |
    v
[45.3 Responding]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX133]

Learning outcomes

You will (1) prepare a design for independent review; (2) respond to review findings; (3) distinguish blocking from advisory findings.

45.1 Preparing for review

Aiyana's revocation design goes to an independent review panel: a cryptographer from another utility, a reliability engineer and an auditor. She sends a package a week ahead with the requirements, threat model, architecture, interface contracts, test plan and open questions. She lists assumptions explicitly, such as that the message queue preserves order per meter. A good package lets reviewers spend their time on judgement rather than on reconstructing the design from scattered notes. She also includes a list of known weaknesses so reviewers start from honest ground.

45.2 Review findings

The panel raises five findings. Two are blocking: revocation messages are not authenticated, so an attacker on the internal network could forge revocations and cause denial of service, and there is no defined behaviour if a verifier misses messages while offline. Three are advisory: naming, dashboard layout and a suggestion to reuse an existing audit store. Aiyana appreciates the first finding particularly: she had protected readings carefully but treated internal control messages as trusted. Each finding is logged with its severity and the reviewer who raised it.

45.3 Responding

For the blocking findings, Aiyana signs revocation messages with a dedicated key held in the key service and verified by every subscriber, and adds a reconciliation step where verifiers fetch the full revocation list on reconnect and compare a hash of it with the published value. For advisory findings she accepts two and declines one with a reason. She re-presents the changed design to the panel, which closes the blocking findings. Independent review caught a flaw that would have been costly in production.

Worked example

The panel finds unauthenticated revocation messages and missing offline behaviour; Aiyana adds signed revocations and reconnect reconciliation and closes both blocking findings.

Synthetic case. The panel and findings are invented.

Errors and limits

Review packages that hide assumptions get shallow reviews. Treating internal messages as trusted is a common design flaw.

Exercises

• EX133 — Review package. List four items in Aiyana's review package. Rubric: 3 = four of requirements, threat model, architecture, contracts, test plan, open questions, assumptions;; 2 = three;; 1 = one;; 0 = none.
• EX134 — Forged revocation. Why were unauthenticated revocation messages a blocking finding? Rubric: 3 = attackers on internal network could forge revocations causing denial of service;; 2 = forgery;; 1 = minor;; 0 = none.
• EX135 — Offline fix. How does the revised design handle verifiers that were offline? Rubric: 3 = fetch full revocation list on reconnect and compare its hash with the published value;; 2 = fetch;; 1 = ignore;; 0 = none.

Synthesis

Independent review with a complete package catches flaws designers miss, especially trust placed in internal messages.

Continue studying — chapter 45 of 50

← Chapter 44 (draft) · Course chapter index · Chapter 46 (draft) →